Testing on Osmar Petry

XState — model UI behavior correctly and make it testable

Sat, 12 Jul 2025 00:00:00 +0000

The problem we’re solving

Imagine you join a company that runs an e-commerce platform. Product asks you to build a search page — the kind of page every user hits dozens of times a day. It sounds simple: a text input, a button, show results.

But then reality kicks in. The page has to handle empty queries, network failures, slow connections, retries, and race conditions where a user submits a second search before the first one finishes. A junior developer might reach for a handful of useState calls — isLoading, hasError, data, submitted — and suddenly you’re juggling four booleans that produce sixteen possible combinations. Most of those combinations are impossible, but nothing in the code prevents them. A loading spinner stays visible after an error. A success message flashes before the data arrives. Bugs creep in not because the developer made a logic error, but because the model itself was never defined.

TDD Effects on Quality and Productivity

Tue, 15 Apr 2025 00:00:00 +0000

Abstract

Systematic review of 27 empirical studies (1999–2014) on Test-Driven Development (TDD). Evaluates internal code quality, external product quality, and productivity. Findings: TDD generally improves cohesion and reduces coupling; external quality gains are observed in 88% of cases; productivity results vary, showing improvements in academic settings but a decrease in industrial environments.

Key points

Internal quality: Improves in 76% of evaluated cases, showing lower coupling, reduced cyclomatic complexity, and higher cohesion (often measured via CK Metrics).
External quality: Positive impact in 88% of the scenarios, with significant defect reduction in critical systems.
Productivity: Mixed outcomes. Academic environments reported speed gains, while industrial settings reported a productivity dip.
Moderators: Prior unit testing experience and continuous integration adoption amplify benefits.
Limitations: Selection bias, uncontrolled environmental variables, self-reported productivity metrics.

Connections

Aligns with Clean Code principles and CK metrics usage.
Supports discussions on technical debt in agile processes.
Contrasts with test-last approaches in rapid prototyping.
Relates to research on developer psychology and TDD adoption.

Questions

How to tailor TDD for volatile requirements?
What is the maintenance cost of large test suites over time?
Are metrics like branch coverage sufficient to gauge TDD effectiveness?
How does TDD coexist with generative AI in testing workflows?

Personal reflections

TDD excels for complex business logic; less so for simple CRUD modules.
CK metrics help quantify internal quality gains.
Variability explains why some companies abandon TDD after superficial adoption.
Integrating TDD with BDD could boost external quality.

Detailed notes

Methodology: PRISMA-based review of 27 empirical studies.
Variables: Internal quality (CBO, LCOM, WMC, RFC), external quality (defects, MTBF, user satisfaction), productivity (delivery speed, cognitive effort).
Results: 76% of cases showed increased internal quality (coupling reduction, ~20% cohesion increase, lower cyclomatic complexity); 88% showed increased external quality (defect reduction); proficiency reached after initial productivity dip, mostly observed in academic scenarios.
Limitations: Many studies lacked controls for prior testing expertise; productivity data often self-reported; publication bias toward positive outcomes.

Example in Go

package cpf

import "testing"

func TestCPFRejectsAllZero(t *testing.T) {
	if IsValid("00000000000") {
		t.Error("All-zero CPF should be invalid")
	}
}

func TestCPFValidKnownValue(t *testing.T) {
	if !IsValid("52998224725") {
		t.Error("Valid CPF was rejected")
	}
}

func IsValid(cpf string) bool {
	if len(cpf) != 11 {
		return false
	}
	for i := 1; i < len(cpf); i++ {
		if cpf[i] != cpf {
			return true // Simplified logic for example
		}
	}
	return false
}

References

Bissi, W., Seca Neto, A. G. S., & Emer, M. C. F. P. (2016). The effects of test driven development on internal quality, external quality and productivity: A systematic review. Information and Software Technology. https://www.sciencedirect.com/science/article/abs/pii/S0950584916300222
Additional supporting documents (ResearchGate, CK Metrics literature).

Gophers Workshop — Deploy-First Go Architecture
Design & Analysis of Algorithms — Course Overview
Assembly Study Plan
BDD
Code Smells and Maintainability
Enterprise UI Development — Testing, Standards, and Ego Control
Testing Concepts Notes

Behavior-Driven Development (BDD)

Wed, 15 Jan 2025 00:00:00 +0000

What Is BDD

BDD bridges the gap between business stakeholders and developers by expressing requirements as executable specifications. Instead of writing tests after the fact, you describe the expected behavior of the system in plain language, then automate those descriptions.

The core loop: Discovery (what should the system do?) → Formulation (write it in Gherkin) → Automation (implement step definitions).

BDD vs TDD

TDD focuses on unit-level correctness (“does this function return the right value?”). BDD focuses on system-level behavior (“does this feature work from the user’s perspective?”). In practice they complement each other — use TDD for internal logic, BDD for acceptance and integration tests.

Testing Concepts Notes

Fri, 15 Jan 2021 00:00:00 +0000

BDD

BDD (Behavior Driven Development) is a method of testing where you use “Given” for the scenario, “When” for the environment of the action, and “Then” for the action.

Imagine AutoLot, a car dealership chain building an online vehicle marketplace. A product manager, a developer, and a QA engineer sit together and write this scenario in plain English:

Given a customer browsing the SUV category
When the customer clicks "Schedule Test Drive" on a 2024 Honda CR-V
Then the test drive request should appear as "pending" in the customer's dashboard

This is BDD in practice — the three roles agree on the expected behavior before any code is written. The npm package jest-cucumber lets you map these Gherkin-style scenarios directly to Jest tests.

Testing Library vs Enzyme