/Tests

How Much Testing Is Enough?

- George Pirocanac tl;dr: George addresses the complexity of determining adequate testing for software releases. It suggests a multi-faceted approach, emphasizing the importance of documenting the testing process, having a solid base of unit tests, not overlooking integration testing, and performing end-to-end testing for critical user journeys. The article also highlights the need to understand various testing tiers, such as performance, load, fault-tolerance, security, and usability testing. Additionally, it stresses the significance of understanding code and functionality coverage and using field feedback for process improvement.

featured in #467

Else Nuances

- Sam Lee Stan Chan tl;dr: "If your function exits early in an if statement, using or not using an else clause is equivalent in terms of behavior. However, the proper use of else clauses and guard clauses (lack of else) can help emphasize the intent of the code to the reader." The authors discuss this with examples.

featured in #465

Tests Too DRY? Make Them DAMP!

- Derek Snyder Erik Kuefler tl;dr: The authors discuss the balance between the DRY (Don't Repeat Yourself) and DAMP (Descriptive and Meaningful Phrases) principles in unit testing. While DRY promotes code reuse and minimizes duplication, it may not always suit unit tests, as it can make them less readable and harder to manually inspect for correctness. The authors argue for prioritizing DAMP in tests to enhance readability, even if it leads to some code redundancy. They illustrate this with an example where creating users and assertions directly in the test, rather than using helper methods or loops, makes the test clearer. They acknowledge the relevance of DRY in tests for certain aspects but suggest leaning towards DAMP for better clarity and understanding in unit tests.

featured in #464

Tests Are Bad For Developers

- Stephan Schmidt tl;dr: Stephan argues that while tests are crucial for software development, they are perceived negatively by developers because they highlight mistakes without immediate benefits. He suggests that tests become a burden when under business pressure, as they can lead to blame for missed deadlines. Stephan advocates for tests as non-negotiable and part of professional engineering, urging QA to support developers in creating effective tests.

featured in #463

Include Only Relevant Details In Tests

- Dagang Wei tl;dr: "A good test should include only details relevant to the test, while hiding noise:" Dadang shows us an example of this by presenting an embedded function where there is a lot of noise, making it hard to tell which details are relevant to the assert statement and testing function.

featured in #461

10 Things We've Learned About A/B Testing For Startups

- Ian Vanagas tl;dr: “In this week’s issue, we explore the secrets of running truly successful A/B tests (and some pitfalls to avoid).” These include: (1) You need to embrace failure. (2) Good A/B tests have 5 traits. (3) Use the “right place, right time” rule. (4) Create a proposal system. (5) Understanding significance. And more.

featured in #454

Simplifying Fluffy Constructors In Unit Tests

- Brian Kihoon Lee tl;dr: Brian discusses the challenges of writing unit tests that become bloated with unnecessary details. “A very common problem is that, over time, objects accumulate fields and subobjects, until it takes significant effort just to construct an object.” To address this, he proposes two solutions: (1) Factory methods: hide irrelevant details, making it easier to write and read tests. (2) Domain-Specific Languages: reduce syntactic fluff, making the code more readable and maintainable.

featured in #451

When, Why, And How GitHub And GitLab Use Feature Flags

- Ian Vanagas tl;dr: Ian discusses several benefits, such as reduced stress on developers, fewer failed deployments, and a higher rate of shipping features. GitLab calculated that fixing an issue without flags is as time-consuming as "developing a whole new feature." The article explores the advantages of feature flags over long-living feature branches for collaboration. Feature flags keep code changes small, make reviews easier, and limit merge conflicts. Both GitHub and GitLab use feature flags not just based on users but also on "actors" like organizations, teams, and repositories to create consistent experiences.

featured in #445

Keeping Figma Fast

- Slava Kim Laurel Woods tl;dr: Figma's journey in evolving its performance testing system as the company scaled. Initially, Figma used a single MacBook for all its in-house performance testing. However, as the codebase grew more complex and the team expanded, this approach became unsustainable. The article outlines the challenges Figma faced, such as the need for more granular performance tests and the limitations of running tests on a single piece of hardware. To address these issues, Figma adopted a two-system approach: a cloud-based system for mass testing and a hardware system for more targeted, precise tests. Both systems are connected by the same Continuous Integration system and aim to catch performance regressions early in the development cycle.

featured in #444

TDD With GitHub Copilot

- Paul Sobocinski tl;dr: The article explores the relationship between Test-Driven Development and AI coding assistants like GitHub Copilot. It argues that TDD remains essential even with AI assistance, as it provides fast and accurate feedback and helps in dividing and conquering problems. The article  shares tips for using GitHub Copilot with TDD, including starting with context, following the Red-Green-Refactor cycle, backfilling tests, and recognizing Copilot's limitations in refactoring.

featured in #441