Unit Testing

 

Unit Tests as Documentation

[...] it’s a good idea to design concrete examples of objects and scenarios before implementing the abstract classes.

 

Unit tests are exactly such examples. They make it easier to understand what happens at runtime. And a well designed unit test is the best way to explain to somebody what the code does. If you ever had to take over somebody else’s code, you know how hard it can be to understand it. Where do you start? Unit tests is a good place to start.

 

So, my suggestion is to think of unit tests as documentation. Write unit tests that are easy to read and that explain the intent of the code.[emphasis added]

 

--http://larsho.blogspot.com/2008/05/use-examples-to-make-your-code-easier.html

 

 

Unit-tests make things go faster

The issue, of course, is speed. For projects that are too simple to require unit tests, or acceptance tests, you can go a lot faster by not writing them. I can write HelloWorld or SquaresOfIntegers in much less than half the time that it would take me to write unit and acceptance tests for those programs. And I know they work because I can run them and manually validate them almost instantly.

 

For large projects the opposite is true; unit tests and acceptance tests make us go faster. The increase in speed comes from reduced debugging time and reduced ambiguity. When programmers follow the three laws of TDD, writing tests and code in a very short cycle, they reduce their debugging time by perhaps as much as 90%. Code written this way is much easier to understand since the tests act as little code examples. It is also much easier to change since the suite of tests act as instant fault detection.

 

Acceptance tests act as executable requirements. When Business Analysts and QA staff write these tests at the beginning of an iteration, they are producing unambiguous requirements. Programmers cannot help but implement the features as specified, since the tests will fail otherwise. So there is much less requirements thrashing and rework.

 

--http://blog.objectmentor.com/articles/2008/02/11/crash-test-dummies [emphasis added]

 

Reference

http://msdn.microsoft.com/msdnmag/issues/06/01/UnitTesting/
http://www.testdriven.net/
http://www.ondotnet.com/pub/a/dotnet/2005/07/18/unittesting_2005.html
http://www.excastle.com/blog/archive/2006/01/14/3669.aspx
http://blog.objectmentor.com/articles/2007/07/17/testing-will-challenge-your-conventions

 

Perhaps this page should be called Testing, or TestDrivenDevelopment or something else?

 

http://blog.objectmentor.com/articles/2007/08/02/not-a-task-but-an-approach
http://weblogs.asp.net/rosherove/archive/2006/10/10/The-Art-Of-Unit-Testing-_2D00_-Download-Chapter-1.aspx

 

automated testing

 

http://pragmaticprogrammer.com/articles/may_02_mock.pdf - Mock Objects

 

http://weblogs.asp.net/rosherove/archive/2007/09/13/throw-away-tests-vs-tests-that-last.aspx - Tests that Last

 

http://larsho.blogspot.com/2008/01/example-driven-development-and-unit.html

 

 

Code Coverage

http://jasonrudolph.com/blog/2008/06/10/a-brief-discussion-of-code-coverage-types/

 

Tracking test cases

http://www.belshe.com/software/ - scroll down to see mention of Test Link
reff’d from http://discuss.joelonsoftware.com/default.asp?joel.3.577988

 

 

NUnit - for DotNet

see NUnit

 

 

Books

FIT for Developing Software -- uses proprietary system

 

 

The Art of Unit Testing

http://the.artofunittesting.com/
http://tools.osherove.com/
http://www.manning.com/osherove/
Ch1_Unit_Testing.pdf Δ

 

 

See Also

DefensiveProgramming
Testing
PHP.UnitTesting
PmWikiDevelopment.Testing

 

 

Category tags

Programming Testing UnitTesting


 

Comments

No comments yet.

 

 

Add Comment

Heading:
 Your Message
 
 Enter value ← Have you entered the code number?
Author: