Skip to content

Test Philosopy

Jump to bottom
Stein Korsveien edited this page Nov 3, 2020 · 5 revisions

easure quality Predict quality

Write the test before the behavior

Difficult to write test after code is written Writing code first gives a desing that is inhernly testable Write less code (You anint gona need it YAGIN). Functinality that are optional will not we written Test tend to be more robust only nessesary method is writen that is need to fullfill tie tests. Access to the state for fixture setup and teardow is based on tests need.

  • Write Executable Spesification
  • Generate Steps
  • Code the Steps
  • Exeute the Executable Spesificaction
  • Test Fails
  • Write Unit Test
  • Exeute a Faiing Unit Test
  • Write Code for the Unit Test to suceed
  • Repaete the writing unit test and code until Exeuting the Executable Spesification suceed

Test are examples

Examples are more easy to envision writing before code than tests. Measure progress of in developement of funtionaliality (definition done)

Write executable spesification and functionality paralell and incremental.(Incremental development)

Easier to stay focused if only a single test is failing. Dose not need to use the debugger much When test is failing it provides defect localization, while the last change we made is still in fresh in our mind.

All test should pass before a new increment ATDD/BDD/TDD

Outside In

  • Write Executable Spesification
  • Generate Steps
  • Code the Steps
  • Exeute the Executable Spesificaction
  • Test Fails
  • Write Unit Test
  • Exeute a Faiing Unit Test
  • Write Code for the Unit Test to suceed
  • Repaete the writing unit test and code until Exeuting the Executable Spesification suceed

Inspired to "think like the client" before think like a developer. Focus first on the interface. The test verifies the use of the system under test and help us identify the senarios the test suite need to cover. Only when all nessecery tests are identified are we "finished" with the spesification. Outside-in development forces us to deal with "dependency problem". We can use Test Stubs to stand in for the software we haven´t yet written, so that the outer layer of software can be executed and tested. Onece the subordinary classes have be coded, could remove the test double for many of the tests. Keeping them provies better defect localisation at the cost of potentially higher test maintenance cost.

Verify states

  • put the SUT into a specific state,
  • execute state change
  • verify that SUT is in the expected state at end of the state

Fixture Desing Test-by-Test

  • Define a minimal fixture for each test method. This gives that each test can be exeuted independet of the other tets.

https://www.growingagile.co.za/wp-content/uploads/2015/04/TestingManifesto.jpg

Clone this wiki locally