TDD tips for scrum teams

“Any tips for getting your Scrum team on board with practicing TDD as a team?”

Yes!

  • It starts with the individual
  • Lunch and Learns
  • Try it with one small story
  • Code Review
  • Ping-Pong Pair Programming
  • Divide and Conquer
  • Book Clubs

Expanding each of those points…

It starts with the individual

A few common situations that prevent teams from adopting TDD include:

  • Can’t make time in current project
  • Legacy system that makes it very hard to practice TDD
  • Team members not willing to try it
  • Lack of support from the business

Those situations should NOT prevent an individual to do it.

Practice TDD on your own time so you can build your skills.

If others see you do it, they may join you. If they do, great. If they don’t, you are still growing.

Lunch and Learn

If you decide to take it on your own, offer lunch and learn sessions for your team to share your experiences, struggles, successes.

The purpose is not to wait until you become an expert; share it as you learn.

Make it a recurring meeting.

Write down ahead of time the things you’d like to share (including how and why you failed, and how you’ve overcome it – or not!).

People aren’t showing up or look uninterested? Consider putting it out as blog posts. Why? There are always people out there who will relate to your struggles and successes.

Try it with one small story

Pick one small story, or a small piece of a story, and commit to doing TDD.

You may fail (many times). You may succeed. Either way, share your findings with the team:

  • was it taking too long?
  • Why?
  • Lack of knowledge? Practice?
  • Difficulties with the legacy code?
  • What kind of difficulties?
  • Too many dependencies?

Work as a team to figure out how the hurdles could be overcome.
Your weaknesses might be someone else’s strengths. And vice-versa.

Share the experience at the sprint retrospective. Figure out the next step and commit to it.

Code Review

When doing code review, start by reviewing tests/specs.

When writing tests first, consider asking for a code review before implementing it, to make sure you have a good understanding of the problem that needs solving.

During that review, share any difficulties you see. The reviewer might know how to help you. And if not, you may find a clear path ahead of you just by articulating your thoughts and sharing it with someone else.

After done with the implementation, ask for another code review. This time, maybe share how you’ve addressed the difficulties. Also, maybe discuss ways how the test code could be improved.

Ping-Pong Pair Programming

Consider ping-pong pair programming: one person writes a test, the other one writes the implementation. Then swap.

Set a time-box. Do not let interruptions get in the way.

Let others know what the pair is up to so they can help avoid interruptions during the time-box.

Share the lessons learned with the team.

Divide and Conquer

Work as a team.

Divide the challenges so that each team member can focus on learning one thing, and then share the findings with the team.

Here are some ideas on what to learn:

  • Test frameworks for the tech stack
  • Testing legacy code
  • Tools such as Cypress.io, Cucumber, SpecFlow, Selenium, etc.
  • How to test code that makes heavy use of libraries or frameworks such as Angular, React, Mass Transit, etc.
  • How to write better specifications in Given-When-Then

Book Clubs

Run book clubs!

Build knowledge and skill together as a team.

Choose a book that seems to fit the team’s current skills, set a cadence (maybe once a week during lunch breaks?), start reading, and discuss the findings together.

Here are a few books you may want to consider: Recommended Reading on Testing

In Summary

I have used all of these techniques. Still do.

I pick and choose whichever one works better depending on my current situation. Sometimes the one I pick doesn’t work on a given team. I drop it, and try another one.

Whether the team thinks of TDD as Test Driven Development or Design and whether they use the terms test or spec, that depends on the team’s maturity. Different people, different backgrounds, different ways to learn.

It all starts with one person. Do not wait for that person. Be that person.

Advertisement

,

Leave a comment

Is it a code smell to use Mocks in unit testing?

Maybe.

But first, I’ll start by clarifying that developers asking that question usually mean “test doubles“, instead of “mocks”.

Some situations that might indicate code smell in tests include:

  • using several test doubles to test one thing
  • complex test doubles setup

Both cases aren’t only an indication of a code smell in the test; they often indicate a bigger problem: code smell in the design!

If the system under test (SUT) requires too many test doubles to satisfy its dependencies, it likely violates the Interface Segregation Principle

A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.

Take the example below:

public class SomeClass(Dependency1 Dependency1,   
Dependency2 Dependency2, Dependency3 Dependency3, 
Dependency4 Dependency4)
{ 
 public void SomeMethod()  
 {    
   if (dependency1.CheckThis() && 
       dependency2.CheckThat() && 
       dependency3.CheckSomethingElse() &&   
       dependency4.FinalCheck())    
   {
       // do the thing...    
   }
  }
}

 

To write a unit test for SomeMethod, we would need mock each one of the 4 dependencies.

By inspecting how those dependencies are used, we could identify a new abstraction that offers what SomeClass needs:

public class SomeClass(Dependency Dependency)
{  
  public void SomeMethod()  
  {   
   if (dependency.CanIDoTheThing())     
   {     
     // do the thing...    
   }  
  }
}

 

Now there’s only one dependency to deal with in tests, and it’s easier to learn what that dependency provides.

An example of code smell

Here’s a test I’ve run into many years ago:

According to the name of the test, it verifies that the “PUT method returns OK and PortfolioModel when service response is successful“.

When I’ve read through the test, these considerations came to mind:

  • Number of stubs and mocks (mockPortfolioService, portModel, response, portfolioModel)
  • Overuse of Arg.Any
  • Arg.Any hiding the meaning/intent of several parameters
  • Unclear what “Configure” is all about (what does it mean to return true from it?)
  • What’s the difference between portModel and portfolioModel? Why are both needed?
  • The file had about 40 tests that looked very similar to this one in terms of mocks and stubs; a product of copy-and-paste.

After raising the issues with the developers on the team, we identified the design issues that resulted in tests having to be written that way. The tests were rewritten to isolate and call out the issue, and a design change was proposed.

Leave a comment

Is it worth writing test code for application logic?

“Is it worth writing test code for application logic (as opposed to business logic)?”

  • Yes.
  • Not all of it.
  • Not always.

Test what yields business value.
Making the development effort more efficient may yield business value.

If application logic is directly related to business value, it needs automated tests.

If lack of tests for application logic delays development efforts (including manual testing), then it’s worth writing tests.

An example…

As a developer, I like being able to take an API contract designed by the team (the URI to the endpoint and the shape of the input and output) and write a quick test for it that we can use to make sure the endpoint works as expected.

This is what such tests look like:

On the left, we see the test. On the right, we see the expected payload and response.

This integration test verifies that:

  • The route exists
  • The json payload can be handled
  • The response gets serialized into the expected json

But not only that, it also verifies any middleware that exists between the route and the controller, so things like authorization, model binders, dependency registrations, etc.

We either find a test harness, or build one, to make such tests easy to write, so there’s no reason not to.

The example above:

  • Does not need any special tool
  • Is written in plain C# and xUnit.net

In summary, when deciding what we should write tests for, “application logic” also comes into consideration.

Leave a comment

Is TDD something you do sometimes or all the time?

That’s another common question: Is TDD something you do sometimes or all the time?

The short answer is neither. Or, “it depends”.

But let’s explore the long answer…

When I started learning TDD, yes, I’d do it all the time.

“But have you always worked on projects where you could do TDD all the time?!”

Most certainly I have NOT!

There are times when I can’t do TDD on a project.
That doesn’t prevent me from still doing it on the side.
I learn and practice it on my own time.

TDD became something I do most of the time, but never all the time.

So when do I NOT do TDD?

There are situations when I specifically choose not to do TDD. Here are some that come to mind…

Exploring a library or framework

When trying to learn what a library or framework can do for me, and how I’m supposed to use it.

Once I identify ways I’ll use it, I often refactor those tests into Given-When-Then, documenting my understanding and assumptions, so I can later remember what parts of it I’m using.

That approach also provides a safety net when consuming updates to those packages (identifying breaking changes and such).

Exploring approaches

Sometimes I need to implement features that currently lack clarity, so I want to gather feedback from stakeholders as soon as possible. I may try a few different approaches and won’t do TDD.

I will, however, use BDD (Behavior Driven Development) to describe, to the best of my ability, the feature we’re building.

Solving small problems

If a problem is too small and yields very little value, I may skip TDD.

Pitfalls of TDD

Remember Design Patternitis? That’s something most developers face when we learn Design Patterns; we start trying to apply them everywhere! As mentioned earlier, TDD is not something to be done always, everywhere, every time.

Another situation I see often is “copy-and-paste inheritance”; tests are initially written carefully following TDD, but then every new test comes from copy-and-paste, without any effort going into refactoring the test code. This is a pitfall that happens in most automated tests, and tests written following TDD can also suffer from it.

But BDD…

I try to do BDD most of the time, even if it means writing the stories and scenarios on a napkin.

Many times I don’t even know how I’ll actually implement the specs/tests, but I still write those English sentences before trying to write any code. No GWT, No Code!

Leave a comment

Differences between TDD and BDD

So what’s the different between Test-Driven Development (TDD) and Behavior-Driven Development (BDD)? I’ve written about that before, but I think that post lacks something more illustrative.

For one thing, I forgot to mention: I’m in the camp that thinks of the last D as design, instead of development. That matters.

I’ve heard developers say things like:

  • “I don’t do TDD anymore, now I’m BDD all the way!”, or
  • “I only do TDD, because I can’t use Cucumber, SpecFlow, or any one of those BDD tools.”

Here’s how I see it…

At some point, I learned to write unit/integration tests in this manner:

Through TDD, I learned to write such test before writing the actual code.

Then I learned about “BDD-style” tests, so I refactored tests such as the one above into the one below:

That was my transition from Arrange-Act-Assert (AAA) to Given-When-Then (GWT).

Then I learned that BDD and TDD go hand-in-hand:

No special tools, languages, test frameworks. In the example above, just plain C# and xUnit.net.

In summary:

  • BDD specifying the desired outcome
  • TDD specifying the desired approach to achieve the desire outcome

Leave a comment

TDD and Legacy Code

 

Is Test Driven Development (TDD) practical when working with a lot of legacy code?

Yes, it is.

There’s an opportunity to practice Test Driven Development (TDD) whenever we write new code in a legacy system. As an example, when writing a new component, service, feature, etc., which is going to be called from the legacy system.

But what if the new code is to be written right in the middle of existing legacy code?

There’s still an opportunity for TDD.

Think what the new code is supposed to do.

Maybe it’s a new if-block that checks some variables in the existing code. That if-block asks the system a question; could that question be implemented as a method, a function, or similar approach, and then called from the existing code?

Or maybe the new lines will perform some sort of task, which is an opportunity to follow TDD to design and implement the new task, and then call it from the legacy code.

What about testing the existing legacy code?

There’s a possibility that the current state of the legacy code is so poor that even changing it to call any new code is so hard that a decision is made to only change the old code, and therefore, leaving no room for TDD.

If that’s the case, there’s still value in at least trying to write characterization tests for the existing code. That’s one scenario where using code coverage can yield benefits, as opposed to the bad way many people use it.

The existing system may be massive, so it’s important to know what we should write tests for.

What do we get from that?

The experience acquired with writing tests for legacy code makes us stronger TDD practitioners; as we experience the pain of writing tests for code that wasn’t implemented and designed with testability in mind, we also apply those lessons when designing new solutions.

But what if I’m working on a greenfield project and there’s no legacy code here?

Isn’t there? Are you sure? Many developers think of legacy code as code written a long, long time ago, often in defunct languages.

Michael Feathers defined legacy code as “code without tests”.

I’ve learned to think of legacy code as “code nobody wants to deal with, with or without tests”.

Sometimes a decision is made NOT to write tests (topic for another post). We can still write the code in ways that people won’t feel compelled to run away from it, even if there are no tests yet.

Sometimes we write tests within a sprint, but we do a poor job at writing those, so tests become “code nobody wants to deal with”.

In case you haven’t already, make sure to read and apply techniques from Michael Feathers’ Working Effectively with Legacy Code.

Leave a comment

Recommended Reading on Testing

I give many talks on Testing (more specifically, TDD, BDD, unit testing, etc.) and often get asked for recommended reading on the topic.

I’ll list here some of the resources I remember I’ve read. Beware that some of them I’ve read a long time ago and do not know how well they’ve aged.

I’ll focus solely on books. I know I’ve read useful blog posts in the past, but I haven’t kept track of the most relevant for me, unfortunately.

Working Effectively with Legacy Code, by Michael Feathers

Amazon link

I’ve read this book twice. The first time was shortly after it came out in 2004. It had been only a couple of years since I learned about unit tests and had already felt the pain of writing tests for legacy code. I remember the book helped me a lot through period, and many of its lessons stuck with me.

I’ve read it a 2nd time earlier this year (2022) and believe the book has aged well, and think every developer should read it at some point in their career.

“oh, but I don’t work with legacy code”. If that’s you, just know that the code you wrote this morning may already be considered “legacy”.

Agile Principles Patterns and Practices in C, by Robert C. Martin

Amazon link

This book came out in 2006, and that’s when I think I’ve read it. I remember recommending it to many developers for several years afterward.

I loved the book because it covered OOP, Design Patterns, SOLID principles, and TDD, often writing tests before refactoring code that would eventually surface as a pattern or principle.

I have not revisited this book in many years, but I know that a lot of the things I’ve learned from it have stuck with me.

The Art of Unit Testing, by Roy Osherove

Amazon link

I’ve read this book around the same time as the other two mentioned above. The Amazon link is for the 2nd edition, published in 2013, which I haven’t read (I see there’s also a 3rd edition, with samples in JavaScript).

I recall learning things about fake objects (mocks, stubs, spies), and I remember recommending this book to other developers back then. If memory serves me right, it’s a short book to read and it provides good information for those getting started into the practice.

Fifty Quick Ideas to Improve Your Tests, by Gojko Adzic and David Evans

Amazon link

This one I’ve read earlier this year and enjoyed it very much, as it validated many of the lessons I’ve learned and applied over the years, and it also gave me some new ideas to try out.

The RSpec Book: Behaviour Drien Development with RSpec, Cucumber, and Friends, by David Chelimsky, Dan North, and others

Amazon link

I’ve read this book when I moved from .NET to Ruby on Rails in 2011. I found this book as I was digging more into Rails, Cucumber, RSpec, Testing, BDD, and all that stuff, and it helped me at the time.

I am positive that things I’ve learned there were brought over when I came back to .NET years later, and I also apply it to JavaScript, TypeScript, Cypress.io, Jest, etc.

Is that all?

Those are books that first come to mind when people ask. I’m sure I’ve read others in the last 20 years, but I didn’t use to keep track of it they way I have been in the last few years, and whichever other books I’ve read didn’t stick with me.

I’ve put out several blog posts on the topic of testing, documenting my questions, confusions, learnings, etc., and will continue to do so.

I also have a list of books on the topic on my “to read” list, and I’ll write up posts in case the books deserve it. 🙂

While the books mentioned here have helped me along the way, the single most important that shaped my practice has been actually doing it!

,

Leave a comment

Improving my Reading System and Leveraging Obsidian

I’ve been working on building my book library and keeping up with my reading habits for years. My process for that has been evolving, and it’s one that I’m moving from Evernote to Obsidian.

My needs:

  • To keep track of what books I own (it has happened that I purchased a book I already owned);
  • To know the formats I own, such as printed, ebook, audiobook. Sometimes I’m listening to an audiobook and realize a printed copy would be better. Sometimes I finish reading a book and want to listen to it to revisit the content;
  • To know what books I’m reading, have read, or that are in my to-read list;
  • To know what books I’ve read in the current year, so I can put together my “Favorite Books I’ve Read in…” blog posts;
  • To know what books I’ve read more than once. Sometimes people ask me for my favorite books, and I want to give them a better informed answer, instead of just relying on what comes to mind first;
  • To know what books are the most recommended to me. It can be through a direct recommendation from friends or co-workers, or maybe through a recommendation found in a book or author I’m enjoying;
  • To find my own notes on the book

This post outlines how I’m now handling all of that. I’m always refining things, but this should describe the core pieces and the direction I’m going. At the bottom of this post you’ll find some resources I’ve used to learn how to put this together.

Tracking recommendations

When I get a book recommendation, I go to Obsidian and invoke the plugin to create a new book note:

The plugin has me type either the book’s name or ISBN. It shows me a list of what it found, I select the one I’m looking for, and complete the operation, which creates a note for me, like so:

I’ve split the window so we can see the markdown down created for the note on the left and the rendered version on the right.

That initial content comes from a template, which I got from the plugin and tweaked to my liking, including the following fields to the metadata you see at the top:

  • status: unread/reading/read
  • formats: ebook/paperback/audiobook
  • recommendations: names and/or places I got the recommendations from
  • finished: the dates when I finished reading the book

I then created a note that uses the Dataview plugin to query my notes and display the results:

The window is split to show the results on the left and the query on the right. Some non-public names are blurried.

The results let me answer the following question: what books have I not ready yet that has more than one recommendation?

Capturing my notes on a book

I take notes on books I’m reading. Whether it’s an ebook or printed book, I highlight passages and write on the book. If it’s an audiobook, I write notes using pen and paper (I actually use a reMarkable, but I’ll save that for another post).

Once I’m done with the book, I review my notes and highlights and consolidate them into that book note I created in Obsidian. My notes include quotes, images, links out to other notes or resources, my own thoughts, etc.

The image above shows my notes on a book on the left and the graph view on the right, which lets me see the connections I have associated with that book.

Tracking books I’ve read or am reading in a given year

As part of my annual review process, I’ve been looking over the books I’ve finished reading in that year and selecting my favorite ones. I put that list out as a blog post, such as this one for 2021. The following note helps me do such reflection:

Again, results on the left, query on the right.

The results include the years when I finished the book; it makes easy for me to see what books I’ve read more than once. Why? Two reasons:

  • When people ask me for book recommendations or my favorite books, I have a better informed answer (instead of just relying on memory);
  • When I see the years when I’ve read a given book, I can draw connections between that and other books or things I had going on around those times

At the bottom of that list (not shown in the capture above), I see a list of books I’m currently reading, which I use when I want to drop in and add a few notes even befor I’m done reading the book.

Listing all books

The simplest query I have is one that lists all books I’ve added:

On that list I can see:

  • All books
  • Their status, cover, and title
  • Recommendations
  • Formats. This one is interesting: if I see a book that’s “unread” and has any kind of format (e.g., ebook), that means I’ve already purchased the book but haven’t read it yet. Also, if I see one like that and it has no recommendations, it just means I’ve heard or seen the book somewhere and want to read it.

About Dataview queries

If you’ve been paying close attention to the queries I’ve shown, you may have noticed the use of two different types of syntax. The reason is the following: for the most simple queries (such as the one to list all books), I use the the standard dataview query; for the queries that need a little more tweaking, I use the dataview javascript API, which provides more granular access to the metadata I’ve added to the notes.

Resources

These are the resources I’ve used to learn how to put together the system outlined in this post.

Leave a comment

Gradually Complementing/Replacing Evernote with Obsidian

The first “personal information manager” I’ve used was Lotus Organizer in the mid 90s. Then there was Microsoft Schedule+, later replaced by Microsoft Outlook, which I stopped using as my personal tool in 2010 or so.

I had a Palm OS around 2000 which I used mostly for note taking. Then a Microsoft Pocket PC in 2003, I think, which I hoped it’d integrate with Microsoft OneNote, which I used for some time.

Then I got into Onfolio (which allowed downloading webpages, organizing them into collections, and building my own knowledge store). A nice little tool that vanished without further notice shortly after getting acquired.

Other than OneNote, all of those things disappeared in a matter of just a few years.

ALL
of them. In just a FEW years.

How can we trust technology when it goes out like that? But I digress…

In 2009, I heard of Evernote, when they were still in Beta. I gave it a try and have been using it since then. Being able to use the same tool seamlessly on a PC, Mac, iPhone, iPad: that’s what got me hooked immediately. I’ve put out many blog posts on how I’ve been using it.

I always keep an eye out for different ways to improve my process and systems. Up until 2020, I haven’t found any reason to replace Evernote with anything else. Compared to the options above, this tool has had a very long and stable run for me. Kudos to them.

Their first version was implemented in WPF, which they’ve learned wasn’t the best choice for their product, and so they rewrote the entire software from scratch after a while. As a consumer of their tool, I remember switching between the two versions going painlessly. As far as I remember, they reached feature parity quickly (at least for the features I used extensively at the time).

But then in 2020 comes another full rewrite: as I understand, they had a different codebase for each operating system they supported (PC, OS, iOS, Android…), which was very hard to keep up with (adding features, fixing bugs…). So this time they went with ElectronJS.

I got into the beta program to try out the new version. I use the tool all day long, on a PC, on a Mac, and on my iPhone. Within a month I had to go back to the previous version, not because of the expected stability issues of a beta version, but because of the large number of missing features I’ve been relying on for several years.

To mention a few of those features:

  • Lack of support for tabs. Here’s one of my use cases for it.
  • Lack of multi-window support (I can open notes in separate windows, but I can’t have multiple Evernote windows)

As someone who works with 3 computer screens most of the day, being able to use those screens effectively is a must, and a tool that doesn’t let me run multiple windows severely impacts that need.

Evernote “Legacy”: multiple windows and tabs

I’ve reported to them all of the use cases and reasons why I was falling back to their “legacy” version, at least on my Mac, which is where I use the tool the most. I’ve kept using the latest version on my PC so I could stay updated on their progress. As I saw their comments about which features we could be expecting soon, and the lack of information on most of the features I was interested in, I figured I should start looking for alternatives.

With so many people swearing by Notion, I looked into it. Didn’t like it.

At a Virtual Brown Bag earlier this year, I heard of Obsidian. It looked interesting, so I noted I should look into it. A few months later, I start hearing good things about it from people whose opinion I trust. So I decided to spend more time on it. I’m liking it.

I’m gradually learning more about the tool. It doesn’t seem to fit all of my use cases yet. But it does work really well for some of them.

For some things, I’ve either completely moved over or started to move parts of it. For example, keeping track of my book reading or how to decide what book to read next, and building and maintaining my book library. Also, keeping track of quotes that inspire me.

I’m not in a hurry. I’m not desparate to use the flashy new toy. And I do see me using the different tools for different parts of my system.

Obsidian has one of the same issues that the Electron-based version of Evernote does: lack of multi-screen support. The latest version added an option to open/move a note into a separate window, but it currently doesn’t work well on the PC and Mac. It seems fine when the windows are showing on the same screen, but it gets really funky when I move the new windows to another screen.

Obsidian: Multiple windows and panes on a single screen

Looking at where Evernote has been putting their effort for the last 2 years and the direction they’re going, and where Obsidian is going with their community plugins and all, I’ll keep working at my gradual transition between the two tools.

I’ll put out separate posts talking about specific use cases.

Leave a comment

May I ask a question?

This has become a personal mission: I want to help build environments where nobody starts a sentence with “may I ask a dumb question?

The group welcomes questions.
The group encourages questions.
People feel safe asking questions.

Questions are asked to:

  • clarify understanding
  • identify coaching and mentoring opportunities

But how do we build such environments?

Here are some ideas:

We may think we know something because “that’s how we’ve always done it”. Well, that’s not true. That might be how we’ve been doing it for a long time since we learned it.

But what if we learned it wrong?

Or what if we learned it right but eventually got sloppy and turned it into the way we’ve always done it?

That question from someone who doesn’t know something might be just what we need to challenge our assumptions, our biases, our beliefs that went into auto-pilot and never gotten updated.

Here’s something I’ve been pondering (by Marie-Christine Gasingirwa):

In life there isn’t a single person that knows everything and there is no person that knows nothing.

It’s not too late to learn because you just need to develop that interest, talk to people, share with them what you have and learn from them.

There is no breakthrough in this world if you are isolated, you can only make a breakthrough by talking to people.

 

Leave a comment