test driven development test complexity the aim is to strive for simplicity in all that you do within tdd thusyou write test that failsthen do just enough to make that test pass (but no morethen you refactor the implementation code (that is change the internals of the unit under testto improve the code base you continue to do this until all the functionality for unit has been completed in terms of each testyou should again strive for simplicity with each test only testing one thing with only single assertion per test (although this is the subject of lot of debate within the tdd worldrefactoring the emphasis on refactoring within tdd makes it more than just testing or test first development this focus on refactoring is really focus on (re)design and incremental improvement the tests provide the specification of what is needed as well as the verification that existing behaviour is maintainedbut refactoring leads to better design software thuswithout refactoring tdd is not tdd design for testability testability has number of facets configurability set up the object under test to an appropriate configuration for the test controllability control the input (and internal stateobservability observe its output verifiability that we can verify that output in an appropriate manner testability rules of thumb if you cannot test code then change it so that you canif your code is difficult to validate then change it so that it isn'tonly one concrete class should be tested per unit test and then mock the restif you code is hard to reconfigure to work with mocks then make it so that you code can use mocksdesign your code for testability