Rafael Quintanilha
Feb 21, 2020 ⋅ 6 min read

Semantic tests with react-testing-library

Rafael Quintanilha Rafael Quintanilha is a frontend engineer focused on developing intuitive and accessible interfaces with React. You can read Rafael's articles on rafaelquintanilha.com, a blog where he talks about technology, web development, mathematics, and whatever comes to his mind.

Recent posts:

Exploring The Javascript Registry For Javascript Module Management

Exploring JSR for JavaScript module management

JSR is designed to serve as a registry for both JavaScript and TypeScript packages, and an upgrade to the features provided by npm.

Oyinkansola Awosan
Jul 19, 2024 ⋅ 8 min read
Error Handling In Rust A Comprehensive Guide

Error handling in Rust: A comprehensive tutorial

Learn to handle Rust errors efficiently to write cleaner, more maintainable Rust code and create a more user-friendly application.

Eze Sunday
Jul 18, 2024 ⋅ 10 min read
Exploring Actions And Request Rewriting In Astro

Exploring actions and request rewriting in Astro

Astro v4.8 ships with server actions and request rewriting. Let’s see how to use these long-awaited (though still experimental) features.

Ivaylo Gerchev
Jul 17, 2024 ⋅ 13 min read
Comparing Fiber Vs Gin For Go Web Development

Comparing Fiber vs. Gin for Go web development

Go Fiber and Gin are two popular Go frameworks that provide extensive toolkits for developing high-performance apps with modern features.

Temitope Oyedele
Jul 17, 2024 ⋅ 8 min read
View all posts

One Reply to "Semantic tests with react-testing-library"

  1. Hi,
    Interesting article but I disagree on some aspects, here are 2 cents of mine to be added to the thinking …
    Each story needs to carry ‘acceptance criteria’ on which tests will be based.
    You don’t create your tests solely based on the story description “as a X I need to do Y so that I get Z”, and you don’t rely on the PM blindly deciding which tests are to be executed.
    How do you know 25 = 77 is representative of the test data you need to use to verify your converter result?
    What about 0, what about -1, what about 12.3 (or is it 12,3 that is accepted as valid input), what about 2.345,67 (or 2,345.67) ? How many decimals are required on the visual or during calculation? Do we use rounding or truncation?
    e.g. convert -17.77777 C to F : is that giving 1,4e-5°F as correct result ? or is it 1.399999998e-5 or 0.0000140000000001805 (sample taken from google search converter) ?
    Also you can’t skip implementation from your tests.
    Let’s imagine a developer detects numeric/alphabetic values in code by testing the keyboard key nrs, that is not good because not all keyboards have same layout and we want to test that (yes, I saw this being done by a developer)
    For ‘clear rules’, you’d maybe like to look at techniques such as equivalence partitioning, boundary value analysis, decision tree …


Leave a Reply