Skip to content

Good practices in testing

Devrath edited this page Jul 4, 2021 · 4 revisions

Having only one assertion for test case

  • This is meaning there should be one test checking per test case.
  • This is important because we give a name for a test case, when a test fails with the name of the test case only we should be able to understand the reason for the failure.
  • Sometimes in a test might require multiple assertions, This is when in a UI test we want. to check the live data is emitted when the progress is starting to load and live data is emitted when the progress had to be dismissed, in any other scenario there should be one assertion per test case.
  • Bottom line is just by looking at function signature we should be able to determine the reason for the failure of the test case instead of analyzing the entire function of the test case and finding out the cause.

Characteristics of a good test case

  • Scope ---> How much of the code in our project is covered by a single test case.
  • Speed ---> How fast the test case runs.
  • Fidelity-> How close our test case is to a real scenario.

Prevention of certain tests

  • Certain tests sometimes fail and sometimes pass, Such tests are called flaky tests.
  • Best way to achieve this is, Always keep each test independent of others.

How many test cases should we actually write

  • Writing test cases is time-consuming and time invested in a real-world project corresponds directly proportional to money.
  • We should write as few tests as possible but this little number of test cases must cover all the important scenarios.
Clone this wiki locally