Unit Testing – Where to Store Test Data

What you're doing is integration testing, because as you can probably tell, your tests have dependencies on other parts of your code. This is fine, but it's good to know when you're looking at articles/examples/etc. online.

Some points to consider, and things to remember:

• Arrange, Act, Assert. All tests have these 3 steps.
  • Need more steps? You're probably testing too much for 1 test
  • No Arrange? You have external dependencies, which almost always makes tests flaky and unreliable.
  • Lots of Arrange code usually means lots of dependencies, and system-state types of dependencies. That's a recipe for fragile code.
  • No Act? Often tests the compiler. Leave that to compiler developers.
  • Lots of Act(s)? You're probably testing too much for 1 test again.
  • No Assert? Often the case when you want to test that "no errors occurred". No errors != working correctly.
  • Lots of Asserts? The code under test might be doing too much/touching too many systems. Try refactoring and testing the individual bits instead.
• Tests should exist on their own. Avoid scenarios where something that tests 3 depends on the code that does 1. Instead, look to replace the code that does 1 with test code. In your scenario: try manually setting the values to what you want them to be in the test's Arrange step, then perform the Act ion (the calculations), then Assert the result.
• Happy-path tests are often a waste of time. Best-case scenarios almost always work. Your tests should be trying to force errors and edge cases.
  • Do you have a test that passes bad streams to be processed?
  • Do you have a test that passes null/non-existant filenames to be processed?
  • What happens if the numeric values to compute are not numeric, or when parsed are huge, or produce huge values when computed?
• Surprisingly writing tests rarely confirms that what you've done is right. Instead they give you insight into how usable, stable, and flexible your design is.

edit> This has already been accepted, but I wanted to add something that I learned long ago via Pragmatic Unit Testing:

Unit Testing with your Right BICEP

• Are the results Right ?
• CORRECT B oundary Conditions
  • C onform to expected format
  • O rdered correctly
  • R ange is correct
  • R eferences to external dependencies are safe
  • E xistence (null etc.)
  • C ardinality
  • T iming (things happen in the right order, with the correct timing)
• I nverse relationships
• C ross-Check results with other means
• E rrors are forced
• P erformance characteristics are within acceptable bounds