It is possible to write software that solves real business problems, cheaply and reliably. The recipe is well known, even though it's not easy to do.
I am a software developer. I'm happy to work as a programmer for ThoughtWorks, mostly in the Milano area. I used to teach at the Università dell'Insubria.
Suppose you have class called "ledger" a method called "calculate" that uses a "Calculator" to do different types of calculations depending on the arguments passed to "calculate", for example "multiply(x, y)" or "subtract(x, y)".
Now, suppose you want to test what happens when you call ledger.calculate("5 * 7").
The London/Interaction school would have you assert whether Calculator.multiply(5,7) got called. The various mocking frameworks are useful for this, and it can be very useful if, for example, you don't have ownership of the "Calculator" object (suppose it is an external component or service that you cannot test directly, but you do know you have to call in a particular way).
The Chicago/State school would have you assert whether the result is 35. The jUnit/nUnit frameworks are generally geared towards doing this.
Both are valid and important tests.Matthew Flynn summarizing the difference between the London and Chicago style of TDD