Scratch Refactoring
Sometimes it pays to do things twice. Continue reading Scratch Refactoring
Exploring Extreme Programming
Sometimes it pays to do things twice. Continue reading Scratch Refactoring
Test-Driven Development is Example-Driven Development, and if you’re not careful, TDD can be like teaching to test. Continue reading Test-Driven Development and Teaching to Test
A ratchet is a mechanism for locking in progress. Frequent builds and regression tests represent ratchets for development. Continue reading Ratchets Capture Progress: Steps to Continuous Integration
Test-driven development uses tension as one of its tools. Continue reading TDD: Tension, Release, and Generalization
When refactorings change the design of a system, they update the tests just enough to accommodate the revision. This keeps the tests working, but tests have other roles. To continue to support these roles, you often need to further modify the tests and add new ones. Continue reading The Impact of Refactoring on Tests
JUnit is a tool for unit testing; Fit is a tool for system testing. Continue reading Tools – Especially JUnit and Fit
Test-Driven Development: A Practical Guide, Dave Astels. Prentice Hall PTR, 2003. This book is a natural complement to Kent Beck’s Test-Driven Development: By Example. Where Kent’s is focused on the background and theory, Dave’s book focuses on tools, GUI testing, and Continue reading Review – Test-Driven Development (Astels)
Domain-Driven Design, by Eric Evans. Addison Wesley, 2004. Evans has developed a pattern language that focuses on how thinking about our domain needs to be of primary importance in developing software. This understanding should show up consistently in how customers Continue reading Review – Domain-Driven Design
“Amazing” is a maze generation program from the book BASIC Computer Games, by David Ahl. (The maze program was created by Jack Hauber). The code is used with permission of David Ahl, www.SwapMeetDave.com. Alan Hensel mentioned using this program as inspiration for Continue reading Refactoring Challenge – The Amazing Maze
Los programadores extremos escriben pruebas antes de escribir el código de producción correspondiente. En “La programación de Probar Primero”, se empieza con una pequeña prueba, luego se escribe únicamente el código necesario para pasarla, y se continúa con la siguiente prueba hasta que el código quede terminado. Continue reading El Semáforo de Probar Primero (The Test-First Stoplight, in Spanish)