Evolving Test Data Arrangement
This post recounts my journey to understand tests data arrangement from before my blogging days. This exploration cemented key lessons in reusability and composition.
This post recounts my journey to understand tests data arrangement from before my blogging days. This exploration cemented key lessons in reusability and composition.
Releasing frequently requires repeatable confidence that changes are safe. Reliably verifying system health requires covering the many failure modes of a system. So, what are those failure modes?
I noticed Scala has several testing libraries that tout pure tests. Is purity desirable for developer tests?
Sometimes performance is an observable domain behavior that belongs in our normal test suite
Lambdas, or functions as values, have worked their way into mainstream programming and transformed development for many programmers.
The TestApi pattern helps decouple tests from our system and enables more stable and reusable tests. I’ve shown how I use the pattern in F#. Now here’s a similar example in C#.
I previously wrote on statistical and mutation testing for UIs. After additional thought, I don’t think UI mutation testing is feasible, at least in the traditional sense. Structure-based generative testing still could be. Lack of Deterministic Errors for Mutation Mutation testing is a tool to measure completeness. It tells us how well our other tests detect possible errors in our code. Mutation testing frameworks measure test suite completeness by crawling the code and injecting breaking changes.
Testing is a broad and essential topic for Software Developers. There is a dizzying diversity of testing approaches for different scenarios. However, the typical developer’s inner loop focuses on a few kinds of tests and test selection. That is, choosing which tests need to be written.
I previously compared the tradeoffs of Gherkin-based and TestApi-based behavior tests. Recently, I realized there is a simple in-between solution: TestApi with Gherkin-style names.
My test types diagram sparked concern that mature process focuses on repeated measured improvement, not specific techniques. This is right, but I don’t see the conflict. Tests are a kind of measure, and the diagram identifies common tests (measures) certain actors leverage to meet larger goals. This raises the question, what do the different kinds of tests measure? Consequently, what do they tell us about our system?