Test Driven Development Tutorial - SeoulSKY/safe-zone-system GitHub Wiki

Test Driven Development

Overview

  • A way of writing code where tests are written before any actual code is written
  • Write a test before writing production code
    • Will not write a new function until there is a first test that fails
    • A test not compiling also counts as a failure
  • Fulfil the test and refactor the code to improve design/cleanliness
    • When refactoring we can have a high degree of certainty that our refactored code is correct if the tests pass.

Goals

  • Specification and not validation
  • Think about requirements before writing code
  • Helps writing clean code that works
  • Continuous delivery (code is robust)
  • Tests themselves are tested (must fail first)
  • Code is easy to test

Steps

  1. Select what feature will be implemented
  2. Write test that validates correct behaviour
  3. Run tests to see if it actually fails
    1. Not compiling also counts as failing(for example if a class that is needed doesn't exist)
  4. Add code to make new test pass
    1. Do enough work for the test suite to pass
  5. Refactor code

Observations

  • Do in very small steps
  • Requires discipline
  • Pair programming helps to keep in track
  • Can write either single acceptance test or unit test
  • Source code is thoroughly tested at confirmatory level
  • Test with purpose
  • Achieve a very high test coverage percentage
  • If not worth testing, why waste time building?

Documentation

  • Well-written test units provide enough specification of functional code
    • Becomes part of technical documentation
  • Acceptance test: define what stakeholders expect (critical requirements)
  • Regression test: detailed executable specifications
  • Not sufficient documentation, but important part of it

IBM Best Practices

  • You are not allowed to write any production code unless it is to make a failing unit test pass.
  • You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  • You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
  • Run all tests that are developed as part of your development pipeline. A failing test must stop the pipeline.

Dockerfiles

  • Can't really test Dockerfiles individually.
    • Could have a smoke test that our docker compose file is able to compile and run each docker container
  • Correctness is intrinsically tested within other specific requirements
  • E.g. If we are test that you can call an endpoint for the server running in the docker container, then when we test that endpoint it will indirectly verify that the dockerfile was implemented correctly.

Resources - Videos to Watch to better understand Test Driven Development