Thread by @rmcomplexity

Software testing has been damaged by strict names. Specifically unit test and integration test.

Use scopes that make sense for the project.

Make tests fast to run and easy to write

Why avoid "unit" or "integration"? And 3 steps to improve tests👇

#100DaysOfCode #freeCodeCamp

"Unit" in unit test is defined as the smallest testable part of any software.

We can go as small as a method in a class. We can end up with one test per method on every class we create (or functions).

We have high code coverage.

This sounds great, what's wrong with this?

👇

Writing one test per method/function you end up with highly coupled tests and tests that need a lot of code to be setup (e.g. mocks)

Consequently, reading and modifying existing tests becomes difficult.

Refactoring something has the extra work of fixing a lot of tests.

👇

Highly coupled tests and tests with high setup overhead turns into a team who dislike writing tests or doing anything related to tests and the testing pipeline.

👇

"Integration Testing" is defined as combining individual software modules to test them

We can go as big as using every external service/API, testing every single call

But, we end up with slow tests and a complicated pipeline

And, we need to setup and teardown a lot of data.
👇

Integrating every single par of an ecosystem and testing it also creates an environment where the team sees tests as a bottleneck rather than a helpful feature of development.

How can we fix this? 👇

Setting up a good testing strategy is no small task.

But, you can start with these three simple-ish steps! 👇

1️⃣ Understand testing scope.

The scope has to be different depending on the service/project you are working on.

If it's a service that relies heavily on an ORM, then tests should use an actual DB, not only integration tests.

👇

2️⃣Run tests as often as possible.

If you're doing TDD, that's great!
If you're not, don't worry, that's also great!

Create hooks to run tests on:
- Commits
- Push
- PRs
- Deployment

Isn't that too much?
👇

Not really. By running tests often you force the team to make sure tests are fast.

Running tests often should not be a bottle neck.

👇

3️⃣Test's code should have the same quality as the application code.

Do as much as possible to make tests readable and easily maintainable.

Document what each test is testing.

Keep set up and tear down code as simple and documented as possible.

If you like this thread please share and follow.

I write threads on the technical and human side of software, at least, twice a week.

Hope this thread helps you.

Thanks for reading!