/Tests

How To Test

- Alex Kladov tl;dr: “This post describes my current approach to testing. When I started programming professionally, I knew how to write good code, but good tests remained a mystery for a long time. This is not due to the lack of advice — on the contrary, there’s abundance of information & terminology about testing.”

featured in #520

Test-Driving HTML Templates

- Matteo Vaccari tl;dr: “When building a server-side rendered web application, it is valuable to test the HTML that's generated through templates. While these can be tested through end-to-end tests running in the browser, such tests are slow and more work to maintain than unit tests. Unit tests, written in the server-side environment, can check for valid HTML, and extract elements with CSS selectors to test the details of generated HTML. These test cases can be defined in a simple data structure to make them easier to understand and enhance.”

featured in #518

Avoid The Long Parameter List

- Gene Volovich tl;dr: “Always try to group data that belongs together and break up long, complicated parameter lists. The result will be code that is easier to read and maintain, and harder to make mistakes with.“ Gene shares examples.

featured in #517

Test Failures Should Be Actionable

- Titus Winters tl;dr: “When a test fails, you should be able to begin investigation with nothing more than the test’s name and its failure messages — no need to add more information and rerun the test.” Titus shares examples.

featured in #513

Generative AI For High-Quality Mobile Testing

tl;dr: “The Developer Platform team at Uber is consistently developing new and innovative ideas to enhance the developer’s experience and strengthen the quality of our apps. Quality and testing go hand in hand, and in 2023 we took on a new and exciting challenge to change how we test our mobile applications, with a focus on machine learning (ML). Specifically, we are training models to test our applications just like real humans would.”

featured in #509

IsBooleanTooLongAndComplex

tl;dr: Complex boolean expressions can be difficult to read and understand, making it challenging for developers to reason about the code's behavior. This post shares a couple of simple techniques to make code easier to comprehend without altering the underlying business logic.

featured in #509

How I Learned To Stop Writing Brittle Tests And Love Expressive APIs

- Titus Winters tl;dr: “Expressive test APIs are a powerful tool in the fight against brittle, implementation-detail heavy tests. A test written with IsSquare(output) is more expressive (and less brittle) than a test written with details such as JsonEquals(.width = 42, .length = 42), in cases where the size of the square is irrelevant.” 

featured in #507

Prefer Narrow Assertions In Unit Tests

- Kai Kent tl;dr: “Broad assertions should only be used for unit tests that care about all of the implicitly tested behaviors, which should be a small minority of unit tests. Prefer to have at most one such test that checks for full equality of a complex object for the common case, and use narrow assertions for all other cases.” Examples are provided in this article. 

featured in #503

A Few Words On Testing

- Thorsten Ball tl;dr: “Too many flaky tests. Too much time spent getting the tests to pass after making a tiny change that I knew was correct but the tests didn’t. Too many integration tests that made people wait 20, 30, 40 minutes until they could merge their change, only to reveal — months later — that they never tested anything. Too many times have I fixed a bug and knew it was fixed because I tested it manually, thoroughly, and was 100% sure that I know how the code works and that this can’t happen again, but then spent hours — 10 times longer than it took me to fix the bug — to write a test only to prove what I knew all along, that the bug is fixed.” 

featured in #499

A Few Words On Testing

- Thorsten Ball tl;dr: “Too many flaky tests. Too much time spent getting the tests to pass after making a tiny change that I knew was correct but the tests didn’t. Too many integration tests that made people wait 20, 30, 40 minutes until they could merge their change, only to reveal — months later — that they never tested anything. Too many times have I fixed a bug and knew it was fixed because I tested it manually, thoroughly, and was 100% sure that I know how the code works and that this can’t happen again, but then spent hours — 10 times longer than it took me to fix the bug — to write a test only to prove what I knew all along, that the bug is fixed.” 

featured in #498