More and more people are asking me about testing resources so let’s put everything I’ve written in one post. Bookmark, share, and, most importantly, please read these. The True Purpose of Testing https://epicweb.dev/the-true-purpose-of-testing… Developers often overlook the fundamentals and rush into writing tests without properly understanding what a test is and what is its function. No test is inherently useful just because it exists. Read this one to learn what makes it useful. The Golden Rule of Assertions https://epicweb.dev/the-golden-rule-of-assertions… There’s a lot of debate over what makes a good test. In this one, I’m defining a short and objective way to grade a test’s quality no matter the language or the tested system. This is, without a tinge of exaggeration, a game-changer in how you approach your tests. Anatomy of a Test https://epicweb.dev/anatomy-of-a-test… Let’s talk about the building blocks that make up any automated test. From JavaScript to Go and Rust—these blocks power tests everywhere. Know your blocks. Implicit Assertions https://epicweb.dev/implicit-assertions… Did you know there’s a way to express expectations in tests without writing “expect”? Those are called implicit assertions and they are tremendously powerful because they help you express more by writing less. Inverse Assertions https://epicweb.dev/inverse-assertions… Sometimes you need to assert that something did not happen. That can be tricky, especially if that something is asynchronous. The last thing you want are false positives. What you actually want is inverse assertions. Making Use of Code Coverage https://epicweb.dev/making-use-of-code-coverage… Code coverage has been an ongoing debate in the engineering circles. Is 100% code coverage in tests good? Bad? When should you strive for it? Why do people say it’s harmful? I’m answering all those questions in this one and giving you practical tips on when to use (and not to use) code coverage. Good Code, Testable Code. https://epicweb.dev/good-code-testable-code… You’ve gathered by now that some code is easier to test than the other. But why? Let’s take a look at the characteristic of code’s testability, what defines it, what is its relationship with complexity, and how to make your code more testable. What is a Test Boundary? https://epicweb.dev/what-is-a-test-boundary… Automated tests rarely involve your entire system (yes, even the end-to-end ones have exceptions). There’s often a place where you draw the line. The boundary. Learn what it is and how to use test boundaries efficiently to focus on the exact behaviors you want to test. Be S.M.A.R.T. About Flaky Tests https://epicweb.dev/be-smart-about-flaky-tests… Flakiness is the scourge of reliability. If you’ve written a test before, you likely had experience with flakiness. But what is it at its core and what causes it? And how should you deal with flakiness? Writing Tests That Fail https://epicweb.dev/writing-tests-that-fail… You write tests for them to fail. We all enjoy a green CI, but the true value of tests is when they fail. What matters is when and how they fail.

The True Purpose of Testing

Source: https://www.epicweb.dev/the-true-purpose-of-testing Let me ask you a question: What are the automated tests for?

Whether you’ve written some tests in the past or not, you’ve likely heard that tests can be useful. And I know you’ve also heard stories about tests that are more of a chore and nuisance than any help. Frankly, I believe both parties are right! But to understand why, I will first let you in on a little secret.

No test is inherently useful just because it exists. A testbecomesuseful when it fulfills its purpose.

So, what is that purpose exactly?

As the name implies, automated tests are here to help us automate something. We take a particular state of our application, perform some actions, and check the resulting system to be what we expect. That’s what any test does, and yet some tests are more useful than others. There is precisely one thing that defines and controls that difference.

The intention

Just as every piece of code exists for a reason, every test exists to verify the intention behind that code.

A paragraph is rendered when the user lands on a page, a request is made when they click a button, the right data is returned when a function is called—there is no count to the things we want computers to do. We then go and use a programming language the computer understands toimplementthat intention.

Sometimes, the intention and the implementation are the same. Take a look at this simple function that adds two numbers:

``

function sum\(a, b\) \{

return a \+ b

\}

`` The intention is for theaddfunction to add any two given numbersaandb. Its implementation quite literally does just that:a \+ b.

In the real world, however, our intentions are seldom as simple as that. We often write hundreds of lines of code to achieve one particular thing. We end up in the situation where the system’s implementation doesn’t directly correspond to the intention behind it. This is when the distinction between the intention and the implementation becomes crucial in the context of testing.

The purpose of tests

A test’s true purpose is tightly connected to theintentionbehind each test case, and can be put together as such:

You write tests to validate the intention behind the system.

It is only when a test validates the intention that it becomes useful.

I’ve seen projects with hundreds, sometimes thousands of automated tests that contributed to nothing. They often broke across pull requests. They were hard to read and painful to navigate. They could’ve been removed tomorrow, and nobody would notice. With time, I came to realize what made them that way.

They had nothing to do with the intention of the code they were attempting to test. Instead of validatingwhatthe code did (the intention), they went in length to focus onhowit did it (the implementation).

“Don’t test implementation details,” is a common advice you hear in automated testing. Hearing doesn’t mean understanding, and understanding doesn’t mean applying. We spend so much time writing code that we often become blind to the line between the intention and the implementation. In the end, we also intend every programmatic choice we make so why not test that?

You can only unlock the value of automated testing once you start treating implementation details as the means to an end, and focus on the larger intention at hand. Your users don’t know how the features of your app work, and neither should your tests. What the users do care about, is that whichever promises your app makes, whichever intentions it allows them to achieve, it does without fault.

Switching to this mental model also does wonders whenever you are unsure what to test. Suddenly, you can approach any system at any scale. When in doubt, test the intention. Always test the intention.

That’s what the automated tests are for.