testing
tdd#
- TDD Anti-Patterns by James Carr
- When Test Driven Development Goes Wrong by Dave Farley
posts#
links#
Vitest runs tests 3x slower than Jest with threads: true (default) setting discusses performance differences between Vitest and Jest, leading to the introduction of vmThreads pool in Vitest 0.34.0 to achieve comparable speeds while maintaining test isolation.
Since resolved.
Mark tests that test overall behaviour other tests expand on in more detail proposes improving Jest’s test output by allowing tests to be marked as dependent on others, helping focus on root causes when failures occur in test suites with overlapping assertions. Utlimately this was closed as not planned and --bail
was suggested as an alternative.
TDD, where did it all go wrong? discusses how Test-Driven Development practice has deviated from Kent Beck’s original ideas, exploring common misunderstandings of the fundamental rules and principles of TDD.
Writing great unit tests best and worst practices explains that unit testing is primarily a design process rather than bug finding, with best practices including test independence, single logical assertions, mocking external services, and clear naming conventions.
Selective unit testing costs and benefits explains how unit testing benefits correlate with code non-obviousness while costs correlate with number of dependencies, suggesting selective application of unit testing based on these factors.
Effective Software Testing: A Developer’s Guide book review describes a systematic seven-step process for creating test cases based on specifications, inputs, outputs and code structure, including techniques for handling equivalence partitions and boundary testing. (reddit)
Jeff Sutherland on Acceptance Test Driven Development suggests that estimating tasks will slow you down.
Write tests. Not too many. Mostly integration argues that integration tests provide the best balance between confidence and speed, suggesting that teams should focus more on integration testing than unit testing, while being mindful not to over-test implementation details.
Why Most Unit Testing is Waste argues that excessive unit testing can be counterproductive and suggests focusing on integration tests that verify valuable business logic. (reddit)
Unit testing vs BDD explains how BDD is essentially unit testing done right - focusing on verifying behavior rather than implementation details. Discusses the practical value of Gherkin syntax and argues that regular code can achieve similar readability.
UnitTest explains how unit tests are low-level tests focusing on a small part of the software system, written by programmers using testing frameworks, and designed to run quickly. Discusses the distinction between solitary unit tests using test doubles and sociable tests that allow real collaborators.
Benefits of functional testing argues that automated functional tests provide more value than low-level unit tests for enterprise applications, particularly for testing business logic and integration points (reddit)
Practical Test Pyramid provides a comprehensive guide to structuring automated tests, explaining how to balance different types of tests from unit to end-to-end, and how to effectively implement them in a continuous delivery pipeline.
A response to Why Most Unit Testing is Waste argues that unit tests are valuable for well-tested parts, decoupled design, rapid feedback and providing context. The article counters the argument that most unit tests should be discarded if they haven’t failed in a year. (reddit)
Programming with GUTs - Kevlin Henney advises on writing Good Unit Tests (GUTs) by treating testing as a form of communication with multiple levels and forms of feedback.
A practical blog on how to write Scenarios using BDD. In my experience writing acceptance criteria does not come intuitively to people. This article breaks down the basics of writing behaviour driven development (BDD) stories. Ultimately acceptance criteria doesn’t need to have the verbosity of GIVEN, WHEN, THEN, but if that structure is not elicted implicitly then it’s a good idea to start writing it out explicitly.