Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><strong>Part I</strong> (Senior Developers and Unit Testing)</p> <p>When I think of TDD or Test Driven Design, the Unit Tests serve the purpose of driving out the <a href="http://www.artima.com/intv/evolution.html" rel="nofollow noreferrer">evolutionary design</a> of the system, hopefully ensuring continuous improvement.<br/> Writing the test shapes the code or highlights issues with a decision that has already been made, hopefully resulting in a refactoring process to increase the quality of design.</p> <p>In my experience, the senior developer is normally the person with the most experience and ability, which means that they should be in a better position to spot these refactoring opportunities. (Detect the code smells)</p> <p>There are three situations I can think of, off the top of my head, where someone else writing the tests for you <em>could</em> be acceptable.</p> <ol> <li><a href="http://en.wikipedia.org/wiki/Acceptance_testing" rel="nofollow noreferrer">Acceptance Tests</a>/Customer Tests/End To End Tests. Call them what you will, but I mean the tests that start at the data input point, (web service, web page, application screen input), and traverse the entire stack of the system, (to a database, call to another service, back round to the input results screen etc). This could be written by someone who is not implementing the details of the individual units that will be exercised by the tests.</li> <li><p>Paired Programming (<a href="http://c2.com/cgi/wiki?PairProgrammingPingPongPattern" rel="nofollow noreferrer">Ping Pong Pattern</a>) -</p> <blockquote> <p>A writes a new test and sees that it fails.<br/>B implements the code needed to pass the test.<br/> B writes the next test.<br/>A implements it.</p> </blockquote></li> <li><p>Bug Fix Tests - When a bug is found, it is often good practice to write a failing test that exposes the defect. Once this test is in place it is entirely possible that someone implements the code that makes the test pass. I don't think that this is all that good an idea as the act of writing the test that fails due to the defect often gives some insights as to how a fix might be produced.</p></li> </ol> <p>In short my answer to your first question would be, no a senior developer should not be exempt from writing unit tests.</p> <p><strong>Part II</strong> (Motivating people to write tests)</p> <p>This is something that I have had problems with in the past. Even though I now try and perform TDD as often is appropriate, it took me a few months to see that there was a real benefit to writing tests.<br/> I believe that trying to show others the benefits of TDD and Unit Testing is quite difficult. It is only when the person experiences for themselves, that 'ah ha' moment when TDD/Unit Tests have highlighted a subtlety in their code, that they might have otherwise missed, or helped them fix a bug in short amount of time, that they see the benefits. Getting them to that point can be quite difficult.<br/> Personally I got there by pair programming in the aforementioned Ping Pong Pattern, working with an experienced TDDer and seeing the code we were writing to solve a non-trivial piece of functionality evolve into what might be called an elegant solution. Followed by that piece of work making it through QA and into the Live Environment without any defects raised against it.</p> <p>In short, I think that pairing with an experienced programmer who is already convinced of the benefits that come from writing Unit Tests is a great way to help someone become motivated to writing unit tests.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload