Troy Foster

Starting Testing:

Last year, at a software conference session Q&A, someone else asked a really good question.

“How do you start testing when you have none?”

Video link

Jump to about 59 minutes in that video to hear when it is asked and for the response.

I was in the audience there and I really liked this question. I have dealt with this situation before. Working in a legacy code base with only manual testing, then adding the first few automated unit and integration tests. Then eventually changing the culture of the organization to be more test first.

Getting the first few tests can be quite difficult.

The test triangle:

Test Triangle with modifications

Part of talking about automated testing is making sure that everyone is on the same page. Ideally with automated tests you should have a bunch of unit tests, each testing individual functions and all their edge cases. Integration tests making sure that different functions and classes work together in an expected way, and End to End tests working your software the way end users do.

London Vs Detroit schools of testing:

London Vs Detroit

With unit and integration tests, there are a few different schools of thought. Should a test case target a single function or can one test case exercise multiple pieces of code? The answer to that question is “it depends”, it depends on the code you are trying to test, what that code does, how interconnected it is, what programming language you are using and probably a dozen other things. More information on London Vs Detroit

Here are my steps for success:

  1. Figure out what is preventing testing.
    • Social
      • Management feature crush preventing taking time to add more tests
      • Schedule crush
      • Developer experience level
    • Code
      • Complexity
      • Legacy
      • Untestable patterns
      • Existing issues
    • Test Infrastructure
      • Makefiles
      • Run scripts
      • Unit test main function
    • Tests
      • Test framework complexity
      • Lack of experience with writing testing code
      • The Unique syntax frameworks use
        • What even is EXPECT_EQ?
  2. Choose a unit testing framework
    • Unit testing frameworks make testing easier.
      • They provide the glue so you can write tests
    • Ask the other developers what ones they have used before
    • Find a survey where developers tell what framework they use
    • Do not home make your own testing framework. If you were not able to get testing started before, what makes you think you can maintain a custom testing framework?
    • Just pick a framework. My recommendation is to pick the most popular one for your programming language.
  3. Start with a simple unit test
    • Test a simple function or class
      • Setters and Getters
      • Or a simple function with well defined inputs and outputs
    • Follow simple Assemble, Act, Assert
    • Find a guide for your testing framework
      • Coworker, course, blog, Youtube/conference talk?
    • These tests should be effectively trivial, if you were to write them in a few months once you have a bunch of tests they would be done really quickly.
    • The whole point of the first tests being simple is to have them not be a blocker for wiring of the test infrastructure.
  4. Wire up test infrastructure
    • Makefiles
    • Unit test main function
    • Run scripts
    • Code coverage
    • et cetera
    • Share initial tests with your coworkers
  5. Test the most difficult code you have
    • This code is likely tightly coupled with other code in your project
    • Draw out what the code does on a whiteboard
    • Identify seams/interfaces where you call that code and isolate it
    • Use dependency injection to insert mock objects for dependencies
    • Share these tests with your coworkers
    • If you fail, test something of moderate difficulty and try again
  6. Address the social issues
    • Management time pressure / Customer Schedule / New feature
      • Coding without tests introduces risks
      • Testing will prevent regressions with the existing code
    • Developers that do not know better
      • Fresh from college or converts from other industries or engineering backgrounds that do not know how to write automated tests
      • Help show them how to test their code
    • Developers that should know better
      • Have been developing since before surge in testing popularity
      • Test the code once when they write it and the tests do not persist in the code
      • Write code too tricky to be tested
      • Show these developers the worth of testing, force them to test their code.
      • Some developers may need a direct order to write tests
  7. Enable testing everywhere
    • Add first simple test cases for every class
      • This way developers cant use the lazy excuse “There were not any test cases for me to copy/paste from”
    • Peer program with coworkers to add tests for their issues
    • Cherry pick new hires first issues to be testable
      • These issues do not need to be adding new functionality, they can be written for the purpose of increasing code coverage.