Automation - The Practice of Cloud System Administration - page 267

Traditional software testing methodology involves first writing code and then writing
code that tests the code. TDD reverses these steps. First one writes the code to test the
code. Running these tests fails because the code hasn't been written yet. The developer
then makes fast iterations of writing code and rerunning the tests; this continues until all
the tests pass. At that point, the developer is done.
For example, imagine writing a function that takes a URL and breaks it down into its
component parts. The function needs to handle many different kinds of URLs, with and
without embedded usernames and passwords, different protocols, and so on. You would
comeupwithalistofURLsthatareexamplesofallthedifferentkindsthatthecodeshould
be able to handle. Next, you would write code that calls the function with each example
URL and compares the result against what you think the result should be. As we saw in
Section 9.3.3 and Section 10.2 , these are called unit tests.
Now that the tests are written, the code itself is written. Step by step, the code is im-
proved. The tests are run periodically. At first only the tests involving the most simple
URLs work. Then more and more fancy URL formats work. When all the tests work, the
function is complete.
Thetests areretained, notdeleted. Later youcanmake bigchanges tocodewithconfid-
encethatiftheunittestsdonotbreak,thechangesshouldnothaveunintendedsideeffects.
Conversely, if you need to modify the code's behavior, you can start by updating the tests
to expect different results and then modify the code until these tests pass again.
All modern languages have systems that make it easy to list tests and run them in se-
quence. They enable you to focus on writing tests and code, not managing the tests them-
selves.
12.7.6 Code Reviews
Code reviews are a process by which at least one other person reviews any changes to files
before they are committed to the VCS. The code review system (CRS) provides a user in-
terfacethatletsthereviewer(s)addcommentaryandfeedbacktoparticularlinesofthefile.
The original author uses the feedback to update the files. The process repeats until all the
reviewers approve the change and it is integrated into the VCS.
Softwareengineersconductcodereviewsonsourcecodetohavea“secondpairofeyes”
finderrorsandmakesuggestionsbeforecodeisincorporatedintothemainsource.Itisalso
usefultodothisonconfiguration files.Infact,inanenvironment whereconfiguration files
are kept in a source repository, code reviews are a great way to ask others what they think
about a change you're making.
CRScanalsobeusedtodelegate taskstootherswhilestillbeingabletoprovidequality
control. This enables scaling of authority via delegation. For example, most companies