Ttdfjt

The main problem with your idea is that you can't just write tests for any code. The code has to be testable.

I.e. you need to be able to inject mocks, separate out the bit you want to test, access state which is changed and needs confirming etc.

Unless you get lucky or write the test first, chances are writing the test means rewriting the code a bit. Which, if you are not the person who write the code in the first place, is going to mean delay, meetings, refactoring etc

The main issue I see here, at the unit level, when I write code, I want to compile it, run it, and remove the most obvious bugs immediately - even when the code is incomplete and I know the unit, feature or function is only partly implemented. And for running the code of a unit, I need some piece of program calling the implementation, usually a unit test or at least a partial unit test. This is not necessarily "TDD style by the book", such a test can be written after or before the code under test.

When one version of my unit is "feature complete" and free of all bugs I can find this way by myself, then it makes sense to hand it over to a second person and let her/him write additional unit tests, or review my code. But to me it makes no sense to hand it over as soon as the compiler shows no warnings, that is definitely too early in case I know I had to explain the tester in detail things which don't work "yet", or will work differently in two hours since I am still working at that piece of code. The necessary communication overhead for this at that level of detail would IMHO not be balanced by the benefits.

So yes, having a second dev writing additional unit tests makes sense, but not for writing the unit tests exclusively.

There would seem to be the possibility for any of the following situations to occur - all of which are undesirable:

Confusion

As Ewan outlined, the CUT might need changing to make it testable. The reason for the change isn't always obvious to the developer (and may cause disagreement) which is exactly why tests are written first.

Contention

Developer A may have completed their code and want it testing. Developer B may also be developing and so may be reticent to park their code to attend to the unit tests.

Context switching

Even if developer B is willing to shelve their development to test the code written by developer A - the change in activity comes at a cost.

It has been accepted for decades that doubling the man power does not halve the development time. Considering the factors I've outlined above, it is hard to see how this arrangement would improve things.

When used in conjuntion with pair programming and TDD this is called Ping Pong Pattern:

• A writes a new test and sees that it fails.


• B implements the code needed to pass the test.


• B writes the next test and sees that it fails.


• A implements the code needed to pass the test.

And so on. Refactoring is done whenever the need arises by whoever is driving.

But you seem to propose that both programmer code with different computers. Doing it separatedly would require to have a very low level specification. This goes against agile metodologies. Every change would need to be coordinated. In TDD you are doing the low level desing on the fly and it is not a problem. I assume that your aproach would require to have some kind of skeletons already coded.

Anyway: You can learn a lot by testing new ways of doing things even if there are not 100% efficient. You can test it and share your real life experience

I'm coming late to this party, but I think I have something to add.

Is it already described as some unknown-to-me methodology and used in software development?

You are describing Peer Testing.

Let's assume we have pairs of developers.

Ah, good ol' Pair Programing.

Each pair is responsible for a part of the code. One from the pair implements a feature (writing code) and the second writes a unit tests for it. Tests are written after code. In my idea they help each other, but work rather separately.

That's not Pair Programming.

Ideally they would work on two similar-sized features and then exchange for test preparation.

That's definitely Peer Testing. Here's an ACM paper about it. I've done this. I've worked where it was a formal part of the Peer Review process. It's helpful, but it's certainly not meant to be the first line of testing, and it's certainly not classic Pair Programming.

Another name for this is Whitebox Testing. Although that definition doesn't concern itself with who's doing the testing as much as with the fact that the tester gets to see the inner workings of the thing they're testing, as opposed to Black Box testing where they only see what goes in and what goes out. Black box is typically what QA does.

The first line of testing rests firmly in the hands of the coder. If it doesn't you're asking me not to test my code myself which I flatly refuse to do. I've been testing my code since I was 10 years old. I might not have tested with fancy unit tests back then but my code was tested. It was tested every time I ran it.

What I expect from a peer tester is tests that add to my testing. Tests that make abundantly clear the issues the peer found with the code when they reviewed it. By expressing these issues with a test it makes understanding what they mean far easier. Infact, I've had technical conversations with peers who just couldn't see the point I was making and then realized the best way to show them the problem was to write a unit test. That is Peer Testing.

Now if you want to give me tests written before I write my code fine. Nothing like a requirements document so formal that it compiles.

I've done DDT (development driven testing, aka. tests after code), pair programming and red-green-refactor TDD for several years each. To respond to your assertions point by point:

tests are written by someone, who can see more about the implementation

The person writing tests needs to know the implementation as intimately as possible, to write tests with good coverage without over-testing. The classic example of this is testing with three inputs when two would prove what you are trying to test. While they can achieve surface familiarity with the code from reading it they will not be able to understand exactly what the original developer went through to get to the current state. So they will have less-than-optimal understanding of the code.

work should be made little faster than pair programming (two features at the same time)

I don't understand why you say that. While someone is writing tests they are not working on new features. You can't magically double someone's capacity for work by giving them two different types of work. In my experience writing tests is generally harder than writing production code, so you could definitely not productively and responsibly work on tests for some code while writing another feature.

both tests and code has responsible person for it

First, tests are code. To the business test code is almost as important as production code, because it enables the business to change the software without fear. Second, this is no different from one person writing the tests and production code, or even a pair writing both.

code is tested by at least two people

No, it's only tested by the person writing the test. Unless you want to use even more time on testing, in which case why stop at two?

maybe searching for errors in code written by person that is testing your code would give special motivation for writing better code and avoiding cutting corners.

Developers (even senior ones) have very different ideas what constitutes "good" code. One person's corner-cutting is another's perfectly valid way of getting to working code ASAP. This is a recipe for blame and for gaming the system.

Red-green-refactor TDD (actually writing a single test before writing production code, running it, seeing it fail, modifying the production code only, running the test again, seeing it succeed, and then refactoring, and not skipping or swapping any of these steps) and code reviews work.

I think that this idea has some upsides:

Le'ts run through them one by one.

tests are written by someone, who can see more about the implementation,

So, you mean that the first developer has spent time writing some implementation, which he is not sure works. Then, another developer comes and writes tests, basing his reasoning on code nobody knows whether it's correct, and hoping that it brings a tactical advantage compared to writing tests only with regards to what the code is supposed to do. If the implementation is incorrect, my opinion will be it brings zero help towards writing tests.

work should be made little faster than pair programming (two features at the same time)

Once both developers have finished their initial development, nobody knows whether either of their code is correct. This still remains to be checked, nobody can tick off any one as done, and nobody can predict when they will be done. Compare this to TDD: You write the test first, then make the test fail, then pass with code. That's code supporting more and more scenarios. That's forward motion.

If you make them progress in parallel, code that could be reused in both features will be written twice, and cost twice more.

both tests and code has responsible person for it,

Look into collective code ownership, as proposed by XP. You will have even more people responsible for the code. If your goal is to share knowledge between developers, why are you trying to segregate them?

code is tested by at least two people

With pair TDD too. When pairing, both people have to agree that written code is adequate or not write it. If that results in a fight, some people in the team have a misplaced ego problem.

maybe searching for errors in code written by person that is testing your code would give special motivation for writing better code and avoiding cutting corners.

Searching for errors implies that at some point, you tolerated that they get in. If they got in, they were unnoticed. Refusing to write tests first is giving licence to errors to get in.

Cutting corner may be unintentional. That's what pair programming is for. Each member of the pair should be instructed with the duty of not letting the other one cut corners, because well, we all do that. That requires leaving your pride in the closet and take it back when you leave office. If you expect your people to be unfailingly rigorous, you're not considering the common situation and set yourself up for failure.

XP says explicitly that all practices XP is made of reinforce each other by covering each other's defects. You should not listen to criticism of any practice of XP separated from the others. No one practice is perfect, TDD is not perfect, pair programming is not perfect, collective code ownership is not perfect, but they all cover for each other.