featured in #467
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
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
featured in #444
featured in #441