On concurrency and Idempotence: TDD just as production code should be thread safe

On Idempotence: TDD just as production code should be thread safe. If it is not then it cannot scale and then you end up with "My build takes too long", and "developers skip tests" and "let us leave to the CI engine to run the tests after commit" and finally a lot of waste generation in your value stream.

Regardless of the scale of your test, did I say before I like Google test sizes definition?, your test must be concurrently idempotent. At a minimum your suite must be concurrently idempotent.

Now that your small and medium tests will always run no matter how other tests work you can safely rely on your Testing framework *and* your build tool to make sure a test does not wait for another in order to finalize.

Of course sooner or later a machine might not be enough to run absolutely all small and medium tests for a big project but then again if your project is such a big monster and you have the right layered architecture why are you building it completely every time you perform a change?. If you have no other option than going monolithic then your suites should be able to run in different machines. This should be easy as you can literally trigger the build and execution of certain suites in different machines relying on plain old remote SSH for example. If you depend on external systems (large tests) though you will need a clustered environment for testing.

I think the Software Community still sees testing as a second class citizen and while nobody argues about clusters, parallelization, thread safe processes and scalability in general when it comes to production code, we still have to hear people looking for workarounds when it comes to testing. Test is serious step that when done correctly is *at least* thought before the production code is written. How would you possibly expect to have clusters of machines to host production code and not clusters of them to run large tests?