In TDD, the test suite can serve as a tool for quantitatively analyzing the qualities present (or absent) in the production code.
One example: A test will need to access the production entity that it is testing, obviously. However, sometimes a test needs to access another entity or entities as well, even though they are not currently under test. We sometimes refer to these collectively as a “fixture” for the test.
Continue reading “TDD and Coupling”
First of all, I like Scrum. I think it can be a great framework when used in the right place. But I also think it must be taught as a tool in your toolbox, not an end in and of itself. This means initial training of Scrum should include more of the flow model (eliminating delays in workflow, feedback and using information) on which it is based. Test-first methods should also be incorporated into this training. This combination allows for teams to avoid most of the pitfalls teams new to Scrum face. I also believe one should look to see if Scrum or Kanban is better for a particular team (or something in between). See first comment for how I do this.
See Why Agile Coaches Need to Know Both Scrum and Kanban.
Continue reading “What I Think About Scrum”
Scrum is a lightweight framework that encourages correct action through performing its ceremonies and practices. While that is great in theory, the lack of the “why” of the ceremonies often has them be not followed.
Consider the “sprint” in Scrum. According to the Scrum Guide, “The heart of Scrum is a Sprint, a time-box of one month or less during which a ‘Done,’ usable, and potentially releasable product increment is created.”
It implies the need to start and finish stories in the same iteration. In other words, one of its objectives is to have a short time between the beginning of a story until it is completed. Here is what this provides. Continue reading “Why Being Explicit in Workflow is Useful: Case Study, Scrum Based on Lean Flow”
Tests pay you back for your effort:
- When you are writing them. They help you to understand the problem you are attempting to solve, they reveal gaps in your knowledge, and lead you to useful questions.
- When they fail. They inform you of a defect, and if written well, specifically where that defect is.
- When they pass. When you are enhancing or refactoring the system, tests passing confirms that you are only making the changes you intend to make.
- When you read them later. Tests capture knowledge that might otherwise be lost. And their accuracy can be instantly confirmed at any time in the future, by running them.
TDD does not cause extra work. It is just the opposite; it is one effort that provides value in multiple ways.
Creating software has several aspects to it.
- Deciding what to create
- How creating new software affects existing software
- How people work with each other
- The process being used to build it
Although all of this creates a very complex process, only the first three are fairly unpredictable, the fourth is not.
Continue reading “Time to Say Goodbye to Empirical Process Control”
Note: This was originally published on the Net Objectives blog on October 6, 2009.
In May 2009, there were some discussions on the Kanban Dev group about types of processes. The dialog that resulted is an important part of the Lean thought process. It is helpful to reproduce it here. The discussion on the thread about quality and pressure helped me to thinking more deeply on what I consider an important issue: Can effective software development be defined.
Continue reading “Types of Processes (by Don Reinertsen)”
A test reacts to everything currently in scope that it does not control. Ideally, that should be only one thing. Everything else in scope must be controlled by the test, or it may react to the wrong thing and give misleading results.
For example, if a production entity uses a service call as part of its implementation, and the service being called is not what the test is testing, then that call must be controlled by the test because it is in scope.
This is a major reason to use a mock object.
Automated tests pass by default. A red test turning green proves everything.
The red test proves the validity of the test (that it can fail). Tests that cannot fail indicates an error in the way they are written.
The green test proves the code is accurate to the test. The code is written to pass the test, and so we know that it will forever be covered by the test going forward.
The transition from red to green proves that the test and the code are connected to each other. This is because we make failing test pass not by changing the test, but by changing the code.
TDD creates, therefore, meaningful test coverage. Nothing else can ensure this.
Errors are going to happen. Trying to prevent them is helpful, but it is often more effective to minimize the impact they have by detecting them quickly.
In software development, waste can be thought of as “unplanned work caused by errors which are usually exacerbated by delays in feedback.” It can come from several sources. Continue reading “Don’t Worry About Process Waste; Worry About Delays & Output Waste”
Test-first yields analysis, it helps us determine what is clear, what is unclear or missing, and ferrets out misunderstandings. Unit tests are unforgiving, they don’t let you get away with anything.
But Test-Driven Development also creates better design. Bad design is hard to test, and so moving tests into a primary position reveals the pain of a bad design very early, before much commitment has been made to it.
Write your tests first, but learn how to listen to what they tell you about your product design.