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. ...
The general approach of using pairs to split the effort of writing production code and writing its associated unit tests is not uncommon. I've even personally paired in this way before with decent success. However, a strict line between the person writing production code and the person writing test code may not necessarily yield results.
When I used a ...
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 ...
These things sound like general good practice being over zealously applied.
But there is a easy answer
the contract stipulate "no changes to the existing code"
There's no arguing with a contract, revert the changes and discipline the programmer.
There would seem to be the possibility for any of the following situations to occur - all of which are undesirable:
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.
Developer A ...
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 ...
There is a lot of confusion about the terms, not all definitions you may find will align.
Containment means the containing object does not directly expose the contained object. It exposes its own interface and may call on the contained object on behalf of the client. So there is no way for the client to mess with the contained object. The containing object ...
For every assertion, ask yourself: does this improve confidence in the code? If two of the assertions test the exact same code and the only difference is what the actual values are in the test then it is very unlikely that both of them add value which the other one doesn't.
Some corollaries to that:
This is why red/green/refactor TDD can be so powerful: ...
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 ...
The connector you are referring to is a package merge. P. 276 of UML 2.5:
A package merge defines how the contents of one package are extended by the contents of another package.
The rules behind that are detailed (in length) in UML 2.5 p. 240.
The circle-plus notation is an alternate to the dashed open triangle (dependency) relation with <<merge&...
There are multiple problems.
One problem is making changes at the wrong time. Usually the sequence is that you create a release candidate, it is tested, unacceptable problems are fixed very carefully and retested, and when QA finds no unacceptable problems it is released.
Making 100s of changes during testing completely messes this up. That's something ...
I am wondering where this "attitude" comes from
Remember what Developers do.
They create software solutions essentially from nothing. Out of thin air. We don't go and chop down some trees for raw materials before we start; we just sit down and start typing (well; some do).
That's almost "God-like" and Developers just love to "think" that they are ...
Some of these changes are sensible and will reduce technical debt, but there is a time for refactoring, and if you're under pressure right now, then this is not that time.
In the light of that, it sounds like they are just procrastinating. They are trying to look busy without having to tackle any of the difficult work that needs doing.
Ask them about the ...
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 ...
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 ...