In JigZaw context, "Divide and conquer" is the concept of dividing a problem into sub-problems until we know how to solve them. This is a well-known technique for handling something complex and/or complicated. This principle is the cornerstone of the test strategy and is the origin for the name JigZaw. Jigsav puzzles got their name from a painting divided into small pieces with a jigsaw. The same as we do to a complicated test problem; we split it into multiple smaller problems.
Divide and conquer can be applied the test code, but also on the architecture and the actual implementation code. A typical example of applying this principle is to refactor a God object and write separate tests for each of the concerns the God object was split into.
JigZaw promotes the concept of using tests to drive the development, but the recommended process is more sophisticated than the test-first principle recommended by eXtreme Programming and TDD. The first part of David Heinemeier Hansson's blogpost TDD is dead. Long live testing. explains some of our objections to the test-first approach.
The size of a problem can be measured in many ways, and no general rule will be appropriate for every context. However, the following concepts may be useful:
For maven users, it is useful to reflect over how maven multi-module break the concept by allowing several pieces in the puzzle to be altered simultaneously. Unfortunately, the world is not perfect, so you can't have complete freedom and self-standing quality modules at the same time (the truth holds both for development and in the real world).
Skip to end of metadata Go to start of metadata