tags:

views:

659

answers:

7

Unit testing is, roughly speaking, testing bits of your code in isolation with test code. The immediate advantages that come to mind are:

  • Running the tests becomes automate-able and repeatable
  • You can test at a much more granular level than point-and-click testing via a GUI

Rytmis

My question is, what are the current "best practices" in terms of tools as well as when and where to use unit testing as part of your daily coding?

Lets try to be somewhat language agnostic and cover all the bases.

+1  A: 

The xUnit family are the mainstay of unit testing. They are integrated into the likes of Netbeans, Eclipse and many other IDEs. They offer a simple, structured solution to unit testing.

One thing I always try and do when writing a test is to minimise external code usage. By that I mean: I try to minimise the setup and teardown code for the test as much as possible and try to avoid using other modules/code blocks as much as possible. Well-written modular code shouldn't require too much external code in it's setup and teardown.

Steve
+2  A: 

The so-called xUnit framework is widely used. It was originally developed for Smalltalk as SUnit, evolved into JUnit for Java, and now has many other implementations such as NUnit for .Net. It's almost a de facto standard - if you say you're using unit tests, a majority of other developers will assume you mean xUnit or similar.

Greg Hewgill
+2  A: 

A great resource for 'best practices' is the Google Testing Blog, for example a recent post on Writing Testable Code is a fantastic resource. Specifically their 'Testing on the Toilet' series weekly posts are great for posting around your cube, or toilet, so you can always be thinking about testing.

Craig
+9  A: 

Ok here's some best practices from some one who doesn't unit test as much as he should...cough.

  1. Make sure your tests test one thing and one thing only.
  2. Write unit tests as you go. Preferably before you write the code you are testing against.
  3. Do not unit test the GUI.
  4. Separate you concerns.
  5. Minimise the dependencies of your tests.
  6. Mock behviour with mocks.
John Nolan
Hi John, can you elaborate on why you wouldn't unit test the GUI?
itsmatt
Yes, Please expand upon why you shouldn't test the GUI.
Malfist
A: 

NUnit is a good tool for any of the .NET languages.

Unit tests can be used in a number of ways:

  1. Test Logic
  2. Increase separation of code units. If you can't fully test a function or section of code, then the parts that make it up are too interdependant.
  3. Drive development, some people write tests before they write the code to be tested. This forces you to think about what you want the code to do, and then gives you a definite guideline on when you have acheived that.
Tilendor
+8  A: 

You might want to look at TDD on Three Index Cards and Three Index Cards to Easily Remember the Essence of Test-Driven Development:

Card #1. Uncle Bob’s Three Laws

  • Write no production code except to pass a failing test.
  • Write only enough of a test to demonstrate a failure.
  • Write only enough production code to pass the test.

Card #2: FIRST Principles

  • Fast: Mind-numbingly fast, as in hundreds or thousands per second.
  • Isolated: The test isolates a fault clearly.
  • Repeatable: I can run it repeatedly and it will pass or fail the same way each time.
  • Self-verifying: The Test is unambiguously pass-fail.
  • Timely: Produced in lockstep with tiny code changes.

Card #3: Core of TDD

  • Red: test fails
  • Green: test passes
  • Refactor: clean code and tests
Jon Limjap
A: 

Don't forget refactoring support. ReSharper on .NET provides automatic refactoring and quick fixes for missing code. That means if you write a call to something that does not exist, ReSharper will ask if you want to create the missing piece.

Thomas Eyde