The Difference Between Unit Testing and Module Testing

A common source of confusion for new software testers is the difference between unit testing and module testing. In general, unit tests are a collection of tests written by a developer during the software development process. Module tests are a collection of tests written by a tester after some code has been written by a developer. There are many exceptions to this generalization but the key point is that unit testing is primarily a development related activity, and module testing is primarily a testing related activity. When a developer creates unit tests during development, this approach is sometimes called test driven development. So which is better, unit testing or module testing? The answer is that the two approaches are complementary, not exclusive. In most cases, neither unit testing nor module testing are sufficient by themselves, and both approaches should be used. Let me explain. Suppose you are creating a PokerLib library for some sort of card game. Imagine you design a Card object like:
 
public class Card {
 private string rank; // A,2,3, . . T,J,Q,K
 private string suit; // c,d,h,s
 public Card(string c) {
  this.rank = c[0].ToString();
  this.suit = c[1].ToString();
 }
 // Rank property, etc.
}
 
An associated unit test might look like:
 
[TestMethod()]
public void CardConstructorTest()
{
 Card card = new Card("Ac");
 Assert.IsTrue(card.Rank == "A");
}
 
This gives the developer confidence that he has written the Card constructor and Rank property correctly. However, there are a total of 52 legal inputs to the Card constructor (Ac, Ad, . . Kh, Ks) and all of them should be tested. In most cases, developers would not want to create 52 separate unit tests for such a simple constructor. But module testing could test all 52 legal inputs and might take the form of a separate test harness program and look like:
static void Main(string[] args)
{
 string[] testCases = { "001:Ac:A", "002:Ad:A", (etc.) "052:Ks:K" };
 foreach (string tc in testCases)
 {
  string[] tokens = tc.Split(‘:’);
  string caseID = tokens[0];
  string input = tokens[1];
  string expected = tokens[2];
  CardLib.Card c = new CardLib.Card(tokens[1]);
  if (c.Rank == expected)
   Console.WriteLine(caseID + " Pass");
  else
   Console.WriteLine(caseID + " FAIL");
 }
 
Module tessting is often used when the development environment includes dedicate software testers, such as most Microsoft product groups.
 
UnitTestModuleTest-UnitTest
This entry was posted in Software Test Automation. Bookmark the permalink.

3 Responses to The Difference Between Unit Testing and Module Testing

  1. Magus says:

    I have a question, from the entry, do you mean that a module testing should test as many aspects as the tester can do? I am puzzling that can we solve the problem in the method of "Equivalence Classing"? Because I think initializing "Ac" or "Kh" is the same equivalence classing. 
    Thanks for you entry 🙂 hope you can answer the question 🙂 

  2. James says:

    Yes, in module testing, a tester should test as many inputs as possible. In most cases, you can\’t test all possible inputs and so you need to use equivalence classes to limit the number of test cases. But in this particular example, a tester should test all legal inputs. Now suppose you have a PokerLib that has a Hand class that consists of 5 cards. There are 52C5 combinations = (52 * 51 * 50 * 49 * 48) / (5 * 4 * 3 * 2 * 1) = 2,598,960 combinations. If you were working for some sort of gambling machine company like Bally, where your code absolutely must be correct, you would need to test all 2 million+ combinations. This would be best done by a tester using module testing with an external test harness. But the developer could still use unit testing to eliminate as many bugs as possible.

  3. James says:

    Chris,
     
    You are quite correct about definitions being the crux of the issue. The IEEE long ago published very specific definitions of unit testing and module testing (and also element testing and component testing) — and they are almost never used in practice. The JUnit/NUnit/XUnit folks adopted the term "Unit Testing" to refer to the development related activity we now automatically associate with the term Unit Testing. Ultimately, terminology is just intended to clarify and simplify communication and I never quibble about formal definitions by the IEE or anyone else.
     
    Your idea of using the term "interaction" is interesting but I\’m not so sure it\’d be an improvement in clarity; all computer programs can be thought of as doing some sort of ineraction that changes machine state.
     
    Maybe we can chat at PNSQC. 

    From: Chris BlainSent: August 29 3:41 PMTo: Dr. James McCaffreySubject: RE: Your blog entry "The Difference Between Unit Testing and Module Testing"

    View the blog entry: http://jamesmccaffrey.spaces.live.com/blog/cns!504C7CC53E7E7FE8!666.entry It seems this discussion always runs into the exact definition of a "unit" and a "module". Your post seems to argue that developers test "units" and testers test "modules". Maybe you could expand on the definitions by clarifying what the goals of "unit" testing and "module" testing are, and then the contrast would be clearer?Taking another tack, I wonder if you replaced "module" with "interaction" if you might be closer to a more useful idea? If we take your definition that testers are interested in module testing, that doesn\’t give me a lot to work with. However interactions are something I think about all the time, and are likely what developers aren\’t thinking about, especially when they didn\’t write the modules that will be interacting.I really enjoy your blog and am looking forward to your presentation at PNSQC.Thanks,–Chris

Comments are closed.