Testing mobile

Testing an untested code-base approach

The guiding principle here is "What would be the worst thing to break in this app?"

We have to narrow it down to one flow at a time (e.g. the book button on the customer app). Then write a step-by-step manual of how to (not) use this unit (from both a end user and developer perspective) and build our test cases from there.

Generally, we want to favor a top-down approach:

• write an e2e test to cover the case

• write integration tests covering edge cases

• write unit tests for everything you can't cover otherwise

While writing new tests for the untested codebase resist the urge to refactor as you go. Testing will probably take a while longer and will be a lot harder. But when refactoring, it is very easy to accidentally change functionality without noticing. Therefore, write comments on what to change, write an extensive test suite and refactor AFTERWARDS.

What not to test

When in doubt, write a test 🤪.

However there are some cases where writing tests doesn't add any extra value. Most of it comes down to:

• Test code you're directly responsible for and don't test implementation details.

• Don't test things twice

When writing tests, focus on integration over unit tests cause they add more value for the time invested and are pretty good at spotting the biggest source of bugs: passing in the wrong parameters.

DO write unit tests though especially for critical and logic heavy code.

On writing good tests

Good tests are independent from all other tests, have a succinct, descriptive name (does x when y) and follow the AAA pattern:

• Arrange (setup the environment)

• Act (run the behaviour we want to assert on)

• Assert

The test data you're using should be as realistic as possible. Try to never use the same value twice to avoid accidental greens (e.g buggyFuncToTest(2,2) ). In the same vein, make sure you can make your passing tests fail. Otherwise they're only giving you a false sense of security.

Proposal

• Start with e2e tests of crucial flows

  • FilterScreenContainer

  • Login/Signup

  • Book a workout

• Have that as a base to write integration tests and refactor LATER as we proceed

(Optional but would love that)

• Change our definition of done to include e2e/integration tests on our implementations from now on

You can have a look here for more testing reading https://kentcdodds.com/blog/unit-vs-integration-vs-e2e-tests