The monthly dose for BDD addicts… In February stories by Kent Beck, Nishi Grover Garg, Shane Hastie & Seb Rose, Stephen McCafferty, Alister Scott and John Tucker…
Subscribe to the monthly newsletter at http://bddaddict.com so that you never miss it! (Did you get the January issue?)
Dear BDD Addicts,
In the last two weeks of January, I was delivering a TDD course for one of my clients where I did BDD courses before. I really enjoyed teaching TDD and BDD at the same client, as they work nicely together. Besides that I was working on the tools I develop myself which was also joyful — this was the payback time of the investment for good BDD scenarios and TDD unit tests. I could put in new features easily and was able to refactor the code to match to the changing needs. Good days!
Did you also have a good start for the year? Or have you rather met challenges? Write a blog post about them and send me the link to bddaddict@specsolutions.eu. There are BDD addicts who are eager to hear your stories!
But now… let’s see the February dose…
[BDD/JavaScript] Learning BDD for React through appropriate examples
The next article can be read in two ways. On the one hand, it is a decent introduction to the tools and technologies you need to use for automating BDD scenarios of a React application. On the other hand, it is also a good log of how someone can get familiar with the concept of BDD: how to find a good example to learn BDD through, how you can evaluate the value of what you have done (e.g. by comparing different solutions) and how to plan the next steps.
React Behavior Driven Development (BDD) (John Tucker, linkedin:john-tucker-23b09458)
[Test Automation] Step by step improvements using reliable tests
Making a perfect end-to-end test is hard. Maybe even impossible. Obviously a good strategy is to reduce the number of these tests and push them down in the test automation pyramid. But having a few good and reliable end-to-end test is still useful, not even to mention those legacy projects where there are hundreds of them already. What can we do with them to make them more reliable? Alister Scott shares some thoughts on this in his post of 2016.
Prioritising Test Reliability over Perfection (Alister Scott, @watirmelon)
[People in BDD] Seb Rose: the man who can operate the agile chainsaw (Podcast)
The podcast that I am sharing now is an interview with Seb Rose at the Agile 2018 conference by Shane Hastie. There is no single topic of the interview, Seb talks about many different things he is dealing with nowadays: about BDD, its relation to TDD, the Cyber-Dojo project but also about certification and the testers role in code reviews.
Seb takes things seriously, that is why I like to work with him on our BDD books. He lives on a farm in Scotland in a house that he has built himself. If someone does, he knows how to operate a chainsaw. But, as he says in the interview, “you can do a lot of damage in software too”. So just like you need to learn how to operate a chainsaw to avoid accidents, you should better take care of learning what you do in an agile project as well. Made you interested? Here is the recording!
Seb Rose on BDD, Cucumber, Cyber-Dojo, Certification and Testers in Code Reviews (Seb Rose, @sebrose; Shane Hastie, @shanehastie)
[TDD] Extreme TDD
Kent Beck is generally known thanks to XP and TDD. XP – extreme programming is a collection of different development practices that he and his colleagues tried to take to an “extreme” level in the late nighties. Many of the practices described in XP are now part of the day-to-day agile development practices (unfortunately many teams lack a few of them still though). In this post Kent Beck shares his thoughts about an extreme version of TDD, the “test && commit || revert” technique. What it is about? I let you read the article. It is super extreme, remember I told you.
test && commit || revert (Kent Beck, @KentBeck)
[Agile Testing] UX tests — learning from users through evidence
I think it was on the P3X conference in London where I saw first a definition for tests by Dan North: “to increase confidence for stakeholders through evidence”. I like this definition but I had problems to imagine how this definition could be applied to subjective topics, like user experience. The blog post by Nishi Grover Garg summarizes the key facts about usability testing with some advices how this could be adopted in an agile project. And I have got the answer for my question as well… the evidence comes from the users!
Making the Case for Usability Testing in Agile Projects (Nishi Grover Garg, @testwithnishi)
[BDD/SpecFlow] Painless feature code behind file generation
Two years ago I shared my thoughts on how we introduced the concept of code-behind files when SpecFlow was created. In that article I envisioned the future without having code-behind files. This has succeeded only partially. The SpecFlow.xUnitAdapter package is used by a couple of teams but we had to realize that the code-behind file generation cannot be avoided in many situations. It cannot be avoided, but it can be made more painless with integrating the generation step to the build process using MsBuild and the SpecFlow.Tools.MsBuild.Generation NuGet package. Stephen McCafferty from the TechTalk SpecFlow team summarized how this works and what to take care of.