Due to COVID 19, all workshops and courses are remotely given for the foreseeable future.

Janet Gregory: Agile Consultant, Trainer, Advisor, Writer, Speaker

Testing And Coding, Not Coding “Then” Testing

code then test quote

This quote was recently published with the question “Hmm😶 What’s your take on this?” You can read some of the comments here.

It made me realize that I should probably write a blog post so that people don’t take out of context what I mean. The quote is “almost” correct, but not quite. One word makes all the difference in the world sometimes.

The quote people most likely hear me say is:

“Throw away the ‘then’ in ‘code then test’ – replace it with ‘and’. And maybe, also reverse the order to say, ‘test  AND code’. Put the test first.”

This came about because teams don’t think about the term ‘code then test’ as a problem. But every time someone says that phrase, it reinforces that testing comes after coding.

Testing and coding shouldn’t be separated as stand-alone activities. They are part of the same development process. Code is not complete without testing – at least some kind of testing, although some testing activities can be completed without writing any code. An example of this might be when we do an experiment or a simulation to test an idea and the team decides not to follow-up.

I was chatting with Paul Seaman about the Linked-In conversation because I saw his name in one of the comments. He was surprised with some of the comments from folks. He asked, “Why do people think BDD and TDD are about testing? Both could be activities which help and influence testing choices but are not testing.”

TDD – it is about design and building testability into the code. BDD (behavior-driven development) and ATDD (acceptance test-driven development) are about getting shared understanding about what we are going to build. That said, I look at as these practices as testing activities since we are testing ideas and assumptions. It is a testing activity that the whole team can participate in to help make sure we understand the feature or story.

This leads into the next point that Paul was concerned about. Sweeping statements such as “the best and most efficient way to avoid bugs in code is to test the requirements” may put emphasis on the wrong thing. For example, the assumption that “better requirements (whatever better might mean) automatically reduces coded bugs” doesn’t hold for him. I like his thought that “Better quality software requires a holistic goodness in systems of development not a singular focus.”

Paul and I have shared many conversations over the past year, and we’ve discussed many of these themes. We both agree the Linked-In thread could have been a great discussion about collaborating through the lifecycle of development – how we influence, assist, and try to make sure the product that build, ships successfully.

It’s not about testing specific aspects like requirement, or code. It’s about how can we give fast feedback. It is one of the reasons, I created this diagram trying to show continuous testing.

shift left shift right diagram

I was influenced by Dan Ashby’s continuous testing model, and I am not completely happy with it yet, but it’s a start. For example, it’s not obvious to everyone what testing activities are happening in the formulate and build section. We need to have fast feedback and practices like ‘show me’ to have the programmer show what he/she coded so bugs can be found quickly and fixed immediately.

In summary, testing is an integral part of the whole development and cannot be separated from the coding aspect of building a product. I think one of my new quotes will be:

quote

 

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email

2 comments on “Testing And Coding, Not Coding “Then” Testing

  1. Hi Janet,

    I speak your opinion Janet and I go even further: for me, developers should spend more than 50% of their time understanding business needs without being imbued with both the words and the stories of the business (Event Storming – narratives composed of business events, User Story Mapping – narrative composed of epics and stories, Example Mapping – business rules illustrated by concrete examples, CRC Cards confirmed by Class Diagram Collaborative Sketching on a whiteboard). After the automation phase in Test First mode should be easy.

    The longer the discovery phase, the less painful the coding phase is; it becomes a side effect of the discovery phase.
    What do you think?

    Bruno

    • Those are useful tools for sure, and I encourage them. However, I wouldn’t go so far to say the longer the discovery phase, the better it is. So much depends on context. For example, if we think about the Cynefin model, if it is simple – we’ve done it before, then perhaps we don’t need to spend any (or hardly any) in discovery. But, if it’s complicated then tools like example mapping are a great way to think about edge conditions and get a good understanding. If we are in the complex area, maybe we need to do many more spikes to understand.

      So, I guess, I’d have to say “it depends”. sometimes we speed through one area, but need to slow down in others.

Leave a Reply

Your email address will not be published. Required fields are marked *