Do you practice Test-Driven Development? Then you know that “classical” TDD uses state verification. To write this kind of test a developer must decide how to represent the result. But what if it is too early for such a decision? What if the system under development is yet too complex and it’s simply unclear how to specify expectations? Classical approach can’t help in this situation. A developer must interrupt TDD process in favor of preliminary analysis and system decomposition by means of upfront design.
Mock Objects technique makes it possible to overcome this shortcoming by focusing on behavior verification. We use mock objects to specify messages the system-under-test should send to other components (collaborators) and describe their reaction. Thereby we can decompose original feature into units of functionality and distribute them between collaborators. Notice, developer can discover collaborating objects right during the test creation. Thus, we use tests to drive the top-down design of a complex system. The further bottom-up development will be driven by classical tests.
In the talk, I’m going to discuss this conception in detail:
I have been a practicing Smalltalker for 10 years soon; teaching Smalltalk programming and Agile Methodologies in Tver State University for a bit shorter time.
Part 1: http://youtu.be/KAwjLacVoY8
Part 2: http://youtu.be/TsiNpO3Ly8k