The monthly dose for BDD addicts… In May #bdd, #specflow and #cucumber stories from Reed Gusmus, Roberto Lo Giacco, Arado Oy, Tomasz Pluskiewicz & Gaspar Nagy.
Subscribe to the monthly newsletter at http://bddaddict.com so that you never miss it! (Did you get the April issue?)
Dear BDD Addicts,
This month happened somehow to bring a lot of BDD introduction session tasks for me. These included a 5-minute elevator pitch for non-IT attendees, a few-hour-long one for professionals who had not heard about BDD earlier and even a 3-day-course for attendees who had used BDD before. So again I thought a lot about the question what BDD is. It is strange from a BDD addict, isn’t it? So even a part of the articles focuses on this question.
Have you encountered a good article regarding this topic or BDD, Cucumber, SpecFlow, Behat or test automation? Send me the link with a few comments to bddaddict@specsolutions.eu, so that I can share it with the other addicts.
Let’s think together about BDD, here is your May dose for it…
[Process] BDD is a set of best practices
There have been several attempts to give a usable definition of BDD. At a panel discussion in CukeUp! 2015 many BDD influencers were talking about that. Still no result. At my SpecFlow and BDD courses I also face the problem that it is not easy to make a simple summary or elevator pitch for BDD. Why?
In my opinion, the reason is that BDD is not a new fundamental addition to the agile concepts, but rather a kind of practical guideline how to use better the power of the existing methods (Dan North calls this “second-generation” methodology). Reed Gusmus’ post gives a short summary on BDD and places it nicely in the landscape of other agile practices.
What’s all the hype with TDD and BDD? (Reed Gusmus, @Reed_Gusmus)
[Process] BDD does not have “test” in the name
The name Behavior Driven Development has been deliberately chosen in a way that the word “test” should not be in there. Not because we don’t like tests. Not because we don’t respect testing or testers. It is because BDD is primarily about specification, so we have to elevate tests to a level that they can be used for discussing requirements. Roberto Lo Giacco says it clearly: Cucumber is NOT a testing framework!
Cucumber is NOT a testing framework! (Roberto Lo Giacco, @rlogiacco)
[Learn:UI Automation] Keep your web automation simple
I think all bdd addict agrees that automating the application at an application interface, e.g. the controller layer instead of the UI has a lot of benefits. Still, there are many cases where UI automation cannot be avoided. At the same time UI tests can be messed up very easily, therefore it is welcome if someone writes about clear and complete solutions. So thanks to Arado for this post!
Testing ASP.NET + AngularJS Web Application using SpecFlow, Page Objects, Selenium and PhantomJS (Arado Oy, @AradoOy)
[Learn:Database testing] When your product is a database tool
If you replace the UI automation of the previous intro to database, you will get what I want to say. If the application you are writing is a database tool, just like the one by Tomasz Pluskiewicz who works on a data transformation tool, your scenarios will consist of database terms. Interesting.
Testing Database Access With SpecFlow and NDbUnit and LocalDb (Tomasz Pluskiewicz)
[Learn:SpecFlow] Tracing test errors
I have recently posted a two-part article about how to improve the tracing of the SpecFlow test errors. You might not think, but a little more care about the way you express your assertions or provide additional information (e.g. a screenshot) about a failure can considerably improve the efficiency of the error investigation. And these are simple things. In my article I am showing a simple technique how to capture additional files on error and also how you can use assertion libraries (in my case FluentAssertions) to provide much clearer errors.
Collect more information on error (part 2) (Gaspar Nagy, @gasparnagy)
