Test Lint Rules Summary
We’ve released Test Lint about 6 months ago. During that time, we’ve added rules to help developers write their tests correctly. So here’s a reminder about the rules that Test Lint includes today:
- No asserts – No test is complete without a pass/fail criteria and Asserts or Isolatr.Verify has to appear once in the test.
- Multiple asserts – if you’re testing too many assertions on different object, that’s a smell for over-specification – separate the tests.
- Logic in tests – As you’re testing your production logic for bugs, is it possible to introduce bugs in test logic? Yes it is. Don’t use if’s, try’s or loops in the test code.
- Dependency between tests – Don’t have one test call another test. Or rely in one test to setup some info for another. This can result in false positives, and in fact, is another form of over-specifications. Instead, extract the common code into a setup function for both tests.
- Time dependent tests – Any reliance on the computer clock in the test is wrong. Tests should be consistent, despite of when they run. Prefer using constant or time data instead.
- Switched “actual” and “expected” values in equality tests – When the test fails, you’ll see unclear error message. Not the one you want to help you solve the problem.
Test Lint also recognizes issues specific for usage in Isolator:
- Missing IsolatedAttribute – This issue can cause tests to show the unexpected and event wrong behavior. Make sure to use the attribute or Isolate.CleanUp to make sure you have an open slate before the next test is run.
- Calling ‘new’ inside a WhenCalled/WasCalled clause – This can cause runtime problems, so Test Lint gives you a heads-up.
But we’re not satisfied with just those. Here’s a glimpse of what we’re working on:
- Duplicating your production code logic inside your test
- Using randomly generated data
There are more coming up, an if you really can’t wait, you can add rules yourself.