Toms Testing

 For ant introduction to Dependency Injection and Service Locator, see the post in the bliki . The problem with dependency injection frameworks are: With the frameworks: I don't want to annotate or anything. I want to write vanilla code There should not be one single place that has to know about every thing else. It is the ultimate violation about the open-closed-principle. Even if it is in main. Configuration explodes with dependencies of nested stuff. Main is on the top level and has no idea what some low level stuff should need Allowing only two presets (like dev and prod) sounds just stupid.  Tests should no have to configure anything they don't need, but should be able to configure anything they want All in all dependency injections feels soooo heavy. Service Locators on the other hand - especially dynamic ones - are very easy to implement, understand and lightweight to use. But they have two major downsides: They hide dependencies You have to implement it in a way that t...

The naive idea is to change the source code and then compile to create a mutant. But this costs a lot of compile time. A better idea: For every file Pass it to an extendable set of mutation-adders Ever mutation-adder adds its mutation wrapped in an if, which checks an environment variable, like EXPERIMENT_ID Every mutation increments the required EXPERIMENT_ID by one We compile the project It runs normally, as EXPERIMENT_ID is not set and thus every if is false, and thus disabling the mutation We now shuffle the set of experiment-ids and set it one after each other, which "causes" the mutation. This is very fast and trivial to parallelize - even on a cluster

For `./test.sh` it is often useful to pass all arguments.  $ cat test.sh python3 manage.py test ${@:1} --parallel --fail-fast This is useful to configure a tool but keep the flexibility of its cli. Open problem: auto-complete