note-Effective Unit Testing by Eliotte Rusty Harold

/**

• https://www.youtube.com/watch?v=fr1E9aVnBxw
• Verify that a know, fixed input produces a known, fixed output
• If it’s a deterministic answer, write a characterization test.
• If the problem is fuzzy or not perfectly defined, test a similar problem with less fuzzy answers.
• Eliminate everything that makes input or output unclear or contingent.
• Never generate random input. Always use fixed values.
• Don’t use named constants from the model code. They may be wrong or change. Prefer literal strings and numbers.
• Don’t access the network and preferably not the file system.
• Control time, the speed of light, or the gravitational constant of the universe.
• Write Your Tests First!
• It’s not just about testing; it’s about software development
• Test first development creates better API because you start with the user, not the used.
• Test first hides implementation and avoids exposing internal implementation details. It avoids brittle, tightly coupled tests.
• Why Unit Tests?
• Unit measn One, Each test tests exactly one thing.
• Each test method is one test
• Best practice: one assert per test method
• Share setup in a fixture, not the same method
• You can have multiple test classes per model class. Do not feel compelled to stuff all your tests for Foo into FooTest.
• Unit also means Independent
• Tests can and do dun in any order
• Tests can and do run in parallel in multiple threads.
• Tests should not interfere with each other
• Tests and Thread Safety
• Don’t use synchronization, semaphores, or special data structures.
• Do not share data between tests:
• Do not use non-constant static fields in your tests.
• Be wary of global state in the model code under test.
• Best practice: one assert per test method.
• Share setup in a fixture, not the same method.
• The Two Least Known Facts of Unit Testing
• 1. Tests do not share instance data.
• 2. You can have many test classes per model class
• Speed
• A single test should run in a second or less.
• A complete suite should run in a minute or less
• Separate larger tests into additional suites
• This is for ease of development.
• Fail fast. Fun slowest tests last.
• Passing tests should produce no output
• Failing tests should produce clear output
• Rotate your test data.
• Don’t use the same data in every test.
• E.G. don’ts set all ints you test to 3. Use 3,33,1117,-98,etc.
• This makes it much easier to see immediately which test is failing and why.
• Flakiness
• Work really, really hard to avoid
• Sources of flakiness:
• Time dependence
• Network availability
• Explicit Randomness
• Multithreading
• System Skew
• Undefined behaviour
• Floating point roundoff
• Integer width
• Default character set
• etc.
• Avoid Conditional Logic in Tests
• Debugging
• Write a failing test before you fix the bug
• If the test passes, the bug isn’t what you think it is.
• Refactoring
• Break the code before you refactor it
• Do the tests fail?
• Check your code coverage
• If necessary, write additional tests before doing unsafe refactorings.
• Development Practices
• Use continuous integration(e.g. Travis).
• Use a submit queue
• Never, ever allow a check in with a failing test.
• If it does happen, rollback first; ask questions later.
• A red test blocks all merges. No further check ins until the build is green.
• Final Thoughts
• Write your test first.
• Make all tests unambiguous and reproducible.
  */