In TDD, tests take actions such as Setup, Trigger, and Verify. Each of these pieces must successfully execute in order for the specification to be verified as accurate to the current behavior of the system.
If there is an external dependency, the test can become vulnerable to a failure of that entity. Continue reading “TDD and Guard Assertions”
Unit testing frameworks, which are the most common tools used by developers to conduct TDD, come with pre-made assertions that can be used to verify the behaviors being specified. Typically, these include assertions such as:
“areEqual()” (value comparison)
“areSame()” (entity comparison)
Developers should not limit themselves to these pre-made assertions. Continue reading “TDD and Naming Part 3: Customized Assertions”
I often hear complaints in the Agile space about how leadership and management don’t get Agile. I think much of that is because of how they are talked to. But I also believe it is the set of practices used makes it hard to see their role without doing a deep study of Agile – something they are neither interested in or going to do (and not something they need to do).
It recently occurred to me that one way to evaluate the quality of an approach is how it affects the conversation with leaders and managers.
I just updated my chapter on Using the Intake Process to Educate Leadership.
Tests often establish example values used to compare the behavior of the system with the actual behavior indicated in the requirements. For example, if we had a system behavior that converted a temperature expressed in Fahrenheit to one expressed in Celsius, then the test that specified this might have an assertion along these lines:
However the use of these values directly in the assertion sidesteps an opportunity to express the meaning of those values in the specification. Continue reading “TDD and Naming: Part 2”
TDD is not really a testing activity so much as it is about the creation of an executable specification. Because of this we value different things than testers might. Naming of tests, variables, and the use of well-named customized assertions are examples.
Test names are sometimes provided by the tools we use. Continue reading “TDD and Naming: Part 1”
sAs I’m completing my book the thought that keeps coming back to me is that when you look at things the right way they get a lot easier. And that much of what’s hard about Agile is that people aren’t looking at it the right way. I don’t mean the “being of Agile” which I believe is a red herring. Let’s run a little experiment. Please explain the following:
For those of you who know bases you’ll figure out this is addition in base 8.
Now, show this to someone who can do addition but doesn’t know bases. See how long it takes them to figure it out. I would guess many won’t.
But what if you had an easy way to explain bases and base addition (I do but it’s not important to the point of this post so I won’t bother here). Understanding bases makes a certain problem easy that is impenetrable when you don’t have that insight.
I believe we have this problem in Agile. People are looking at examples of what to do (practices) instead of the equivalent of bases in Agile. I’m not saying it’d be easy (e.g., add 142372341539243 and 524234714234 🙂 ) but it’d be easier. 🙂
I’ve written a chapter in my book on The Relationship Between ATDD and Design Patterns. Essentially, ATDD provides us with quality acceptance criteria in the form of test specifications. We can use these to design our code from a behavior point of view instead of from an implementation point of view.
Doing this makes for more testable code, a quality highly correlated with other code qualities we want – strong cohesion, loose coupling and no redundancy. Design patters provide us with a method for combining these high quality objects together through the Gang of Four’s mantra’s of designing to behavior, using variation and encapsulating variation – in this case variation of type.
In the Agile world where requirements evolve, ATDD and Design Patterns Thinking work together to enable emerging designs from emerging requirements.
It’s nice to see the Scrum community finally accepting the importance of Lean and Kanban. But putting Lean/Kanban practices into Scrum does not make Scrum the same as Lean.
Perhaps the biggest different between the two is where our attention is when we have to remove an impediment. In Scrum our attention is “how do we remove the impediment by being faithful to Scrum’s practices.” In Lean, there is no attachment to any practice. Instead we ask “how do we remove the impediment by attending to Lean principles?”
In Scrum’s case, the assumption is that the team will figure out how to alleviate this impediment. But the best solution may not include having a stable team. For example, when multiple teams are working on a common codebase it may be best to dynamically form a feature team to work together (think of this as spontaneous mobbing).
This is a practice that I first used over a decade ago when test platforms were highly constrained. Immediately worked well and adoption was simple. The 7 teams that worked together to do this were following Scrum (with difficulty) before shifting to this model. Afterwards, they were no longer doing Scrum. We had to think in a Lean way to get to a Lean solution.
TDD, when conducted as a specifying activity, is an aspect of Behavior-Driven Development (BDD). Behavior is what we specify and is what we “drive” into the system using tests. Therefore, when structuring the tests in TDD we can be guided by the language of BDD: Given, When, Then.
Continue reading “TDD and Test Anatomy”
SAFe is not Agile if you are planning 3 months ahead
For companies that couldn’t get anything done in a year and are now getting things done in 3 months, SAFe is great. But don’t consider it Agile.
Quarterly planning presumes more certainty than we have. It’s waterfall thinking. Going from 12 to 3 months is an improvement. But don’t stop there.
If you are a development group of less than 300 people you probably could be doing 2 week plannings or even flow. Every now & then you can do a big room planning for the social benefits that provides, but it’s not needed for planning.
Long planning periods:
- require reworking requirements in last couple of sprints
- loses focus on realizing value
- makes it more likely that features will be bigger than needed
- loses focus by teams on releasable value
- results in more work being injected into already planned work
- has the refinement of any stories pushed out of the PI due to new work be waste
- makes it harder to pivot
- causes a loss in a sense of urgency
- requires more refinement up front without advantage of feedback
- establishes a baseline of “not good but good enough” so improvement stops
It’s fine to do high level quarterly planning but then work in a flow model to implement it.