Labels

.net (1) *nix (1) administration (1) Android (2) Axis2 (2) best practice (5) big-data (1) business-analysis (1) code re-use (1) continuous-integration (1) Cordova-PhoneGap (1) database (2) defect (1) design (3) Eclipse (7) education (1) groovy (2) https (2) Hudson (4) Java (1) JAX-RS (2) Jersey (3) Jetty (1) localization (1) m2eclipse (2) MapForce (1) Maven (12) MySQL (1) Nexus (4) notes (4) OO (1) Oracle (4) performance (1) Perl (1) PL/SQL (1) podcast (1) PostgreSQL (1) requirement (1) scripting (1) serialization (1) shell (1) SoapUI (1) SQL (1) SSH (2) stored procedure (1) STS (2) Subclipse (1) Subversion (3) TOAD (3) Tomcat (4) UML (2) unit-testing (2) WAMP (1) WAS (3) Windows (3) WP8 (2) WTP (2) XML (4) XSLT (1)

Monday, April 25, 2011

Notes on early TSS.NET Unit Testing article

  • Article
  • "A test fixture is a class that contains a series of test methods ... This grouping is important for two main reasons: one, it creates a subset of tests that can be run as a group, separate from other groups of tests, and two, it provides a level of granularity for controlling the lifecycle and context of a test."
  • For database code, article suggests using stored procedures to initialize database for a unit test and calling these stored procedures in SetUp and TearDown.  Also, more specific stored procedures to create additional data for specific tests.  More ideas:  Get Test Infected with NUnit: Unit Test Your .NET Data Access Layer 
  • a mock object will have the same interface as the "real" object.  The implementation of the mock object should track usage, allowing you to determine if the right calls were made (by the tested code), and expose any methods/properties that test code might use to evaluate results.  Rather than implement yourself, can use a dynamic mock object library such as NMock
  • Nester helps verify code coverage by unit testing:  "involves modification of programs to see if existing tests can distinguish the original program from the modified program" (mutation testing)
  • So that test code doesn't force breaking encapsulation of the tested code, have tests reside in same assembly and namespace as code being tested.  Then non-public methods/properties that need to be accessed by test code can be marked with internal modifier