Jeffrey Palermo 2:12 pm on November 21, 2005  

Microsoft’s guidance for unit testing actually describes integration testing – level 200

I commend Microsoft for putting a big emphasis on automated testing.  This is a big step for the software industry as a whole to embrace automated testing.  The hardware industry has already discovered this and has a built-in self-test in almost every device.  Likewise, software should have built-in self-tests to ensure that everything is working.


Microsoft has provided Unit Testing and Generating Source Code for Unit Test Frameworks Using Visual Studio 2005 Team System.  In this article they describe how to unit test some code using Team System’s automated testing features.  The problem is that what is actually described is integration testing.  The tests call a BankAccount object and exercise some methods.  There is no mocking(stubbing) of BankAccount’s dependencies, so this cannot be a unit test.  If BankAccount actually works, it will have to communicate with some dependency unless this BankAccount keeps everything in memory.


Here are some recommended “unit tests” from the article:


  • Constructor Test—To make sure your object loads properly, with the correct information.
  • PositiveLoadScalarTest—To test the successful Load of a Customer that exists in the database.
  • NegativeLoadScalarTest—To test the unsuccessful Load of a Customer—that is, one that does not exist in the database.
  • PositiveLoadTest—To test the successful load of Customers, based on known data.
  • NegativeLoadTest—To test the unsuccessful load of Customers that do not exist in the database.
  • NegativeValidationTest—To make sure your validation logic is working correctly.

    • Clearly, the assumption is made that a database is in the testing stack.  This disqualifies the tests from being unit tests because they include a dependency and test more code than the “unit” – BankAccount component. 


    Automated testing is very important, but I must clarify some points in this article.  The testing described here is “integration testing”.  This kind of testing is important too, but it’s important to make the distinction.  Unit tests test at the unit level and exclude a database.  Unit tests are fast and can run on any workstation, not just a specially configured development environment.


    Integration tests include multiple components of a system and make sure the pieces work together.  In an integration test, it is appropriate to include multiple components including a database.  For unit testing, including a database is not appropriate.