the first point really doesn' justify the time it takes to write testwe can simply test the code directly in the interactive interpreter but when we have to perform the same sequence of test actions multiple timesit takes less time to automate those steps once and then run them whenever necessary it is good idea to run tests whenever we change codewhether it is during initial development or maintenance releases when we have comprehensive set of automated testswe can run them after code changes and know that we didn' inadvertently break anything that was tested the last two points are more interesting when we write tests for codeit helps us design the apiinterfaceor pattern that code takes thusif we misunderstood the requirementswriting test can help highlight that misunderstanding on the other sideif we're not certain how we want to design classwe can write test that interacts with that class so we have an idea what the most natural way to test it would be in factit is often beneficial to write the tests before we write the code we are testing test-driven development "write tests firstis the mantra of test-driven development test-driven development takes the "untested code is broken codeconcept one step further and suggests that only unwritten code should be untested do not write any code until you have written the tests for this code so the first step is to write test that proves the code would work obviouslythe test is going to failsince the code hasn' been written then write the code that ensures the test passes then write another test for the next segment of code test-driven development is fun it allows us to build little puzzles to solve then we implement the code to solve the puzzles then we make more complicated puzzleand we write code that solves the new puzzle without unsolving the previous one there are two goals to the test-driven methodology the first is to ensure that tests really get written it' so very easyafter we have written codeto say"hmmit seems to work don' have to write any tests for this it was just small changenothing could have broken if the test is already written before we write the codewe will know exactly when it works (because the test will pass)and we'll know in the future if it is ever broken by change weor someone else has made secondlywriting tests first forces us to consider exactly how the code will be interacted with it tells us what methods objects need to have and how attributes will be accessed it helps us break up the initial problem into smallertestable problemsand then to recombine the tested solutions into largeralso testedsolutions writing tests can thus become part of the design process oftenif we're writing test for new objectwe discover anomalies in the design that force us to consider new aspects of the software