Version 10 by Kerry Lamb
on Jan 28, 2008 14:03.

<< Changes from 9 to 10
compared with
Current by Kerry Lamb
on Jun 17, 2009 16:19.

 
Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 1 changes. View first change.

  The lowest level of testing performed during software development, where individual units of software are tested in isolation from other parts of a program.
  The lowest level of testing performed during software development, where individual units of software are tested in isolation from other units; the smallest software component.
  
 h2. Definition
  
 Unit testing is the first level of testing. Each module, object, page, or function is tested to ensure that the edits, processes, and outputs conform to the specification or expectation.
  
 Unit testing goals are the same on all platforms. The intent is to ensure that the unit performs all the functions in the specifications, handles error conditions appropriately, and has expected performance. Of all the types of testing, unit testing needs to come closest to 100% code coverage.
  
 One definition of Unit Tests can be found at the [Extreme Programming website|http://www.extremeprogramming.org/rules/unittests.html]. An important point made in that definition is, "Unit tests enable collective code ownership. When you create unit tests you guard your functionality from being accidentally harmed. Requiring all code to pass all unit tests before it can be released ensures all functionality always works."
  
 An article called [Straight Talk on Unit Testing|http://www.idinews.com/unitTest.html] at Information Disciplines, Inc. makes the point that Unit Testing is not new and is not methodology dependent. The author asserts that COBOL is usually written in a way that does not support unit testing, because the modules are written without the ability to be broken free of the rest of the monolith.
  
 In languages that support unit test frameworks, the process can be automated. Where test frameworks are not implemented, a common practice is to run the code fragment repetitively, feeding valid and invalid data to ensure each is handled properly. In many cases, even if the process isn't well suited to the standard test frameworks, a test harness can be built that automates repetitive tests. See the CAATest folder in the SourceSafe CAADotNET project for examples of using a test harness.
  
 h2. When to Start
  
 Unit tests are defined and executed before the code is considered complete. The code should pass all unit tests before the module, page, or object is checked into source code control as a "finished product." In the Test-Driven Design approach, the unit tests are written before the code to be tested.
  
 When the code or environment is modified, unit tests are repeated. Automated unit testing allows a reliable repetition of all the tests.
  
 h2. Examples and Ideas
  
 *Web Pages*
  
 Web pages that include scripting can use [jsUnit|http://www.jsunit.net/] for unit testing.
  
 *DFDS forms*
  
 DFDS forms are not well suited to unit testing. See the page on functional testing for a description of an appropriate testing method.
  
 *SQL*
  
 Stored procedures are routinely executed with all the possible combinations of valid and invalid parameters to ensure the edits work and the database update occurs as expected. This is easily automated by creating a class or function that executes the stored procedure and another class or function to pass variables for the procedure that knows whether the passed variables should result in an error or not. An example from [UW Travel|Testing a Stored Procedure] is even simpler, in that it exercises a stored procedure and prints out the results.
  
 *C# and Java*
  
 A testing framework for C# or Java greatly assists the implementation of unit tests. See [CAA Money class|nunit Testing] example. Many examples can be found on the Web by doing a search on Unit Tests.
  
 *COBOL*
  
 Unit tests in COBOL can be done by inserting specific debugging code into the application.
  
 h2. Tools and Reviews
  
 C# - see the [NUnit|http://www.nunit.org/]site for a tool that plugs into the Visual Studio .NET environment. Directions for installation and use are found at [http://www.nunit.org/documentation.html]
  
 Java - see the [JUnit|http://www.junit.org/index.htm]site.
  
 Javascript - see the [JSUnit project site|http://sourceforge.net/projects/jsunit/].
  
 h2. Local Resources
  
 Scott Stephenson and Joe Frost gave a presentation called "Dude, What's This Supposed to Do, Anyway?" at CUMREC 2005 that included a description of the Test Driven Design process. See also [UW Technology .NET developer page|https://ucsdocs.admin.washington.edu/docs/uwnetid/sg/default.aspx] for other links.
  
 h2. Expected Costs
  
 Unit testing, done at the time of development, is a simple task when working with nUnit or jUnit. If you need to build a test harness, the cost is a little higher. If you do neither, the manual process of testing each function can be very tedious, but is not something to cut from the schedule.
  
 h2. Expected Benefits
  
 A unit test suite makes all later testing simpler, since many common tests will have been performed during development. Functional and integration testing should be able to focus on interactions between units rather than handling bad data or correctness within units.