The problem with the 1:1 class-to-test-file convention is that you're introducing mechanical friction that impedes redrawing boundaries within the objects that collaborate to produce a feature. In fact, I hear a lot of programmers refer to "the test" as being the file itself. This seems backwards. To me, a unit test is one of those methods that start with def test_* (or the it/specify block, if that is your tool of choice). It would be poor form for a test class to include unit tests that exercised the interfaces of different objects, but from time to time I'm satisfied when test coverage for an "inner object" lives in the "outer object's" test, by going through the outer object's API. Usually this happens when a project is getting started, and the ideal boundaries for objects is still unclear.
The problem is – and I want you to think carefully about this next statement – a one-to-one correspondence implies extremely tight coupling.
Think of it! If the structure of the tests follows the structure of the production code, then the tests are inextricably coupled to the production code – and they follow the sinister red picture on the left!