In the first part of this article I described why it is important to provide more information on errors and how you can collect useful artifacts (screenshots, log files, etc.) in an
[AfterScenario] hook. In this part I would like to explain how to write more informative assertions.
Many teams who use SpecFlow setup their continuous integration environment with Microsoft Team Foundation Server (TFS) or its cloud based service, the Visual Studio Team Services (VSTS, fka VSO). TFS/VSTS has an improved build system, where it is much easier to setup and customize builds. Regardless of the fact, which unit test provider you use for SpecFlow, it is super easy to setup a build to run your BDD scenarios, because all the major unit test frameworks provide the necessary adapter for it (this is the same adapter that you need to run the tests from the Visual Studio Test Explorer Window).
Since the infrastructure is relatively new and very generic, it is sometimes hard to find information on particular questions. For SpecFlow users one of the most typical question is, how to run only specific scenarios (marked with a tag) in a TFS/VSTS build.
Dear BDD Addicts,
April is the month when trees blossom, bees whir and BDD addicts come together in London in order to spend two days with talking about BDD at CukeUp! conference. Is there a need for a BDD Addict Newsletter in April at all? Of course, there is![read more…]
When BDD scenarios are turned into executable automated tests, they usually automate the application together with its dependencies (e.g. end-to-end with browser automation or headless with controller-layer automation). This ensures that the application works as a whole, but unfortunately it also makes the analysis of a failing test harder. So many things can go wrong, especially if you run these tests on a build server, where the monitoring of the different actions is limited. Because of this, providing more information on the context where the error has happened (screenshot, log, last transaction, etc.) is really helpful. In this post I show you how this can be done.
Dear BDD Addicts,
Welcome to the second BDD Addict newsletter. My plan is to collect interesting posts, articles and events about behavior driven development, SpecFlow, Cucumber moreover also test automation and agile testing. I’m following many channels, but surely not all. So if you have seen something that fed your addiction, just send me the link with a few comments to email@example.com.
How do you know that you are already a BDD addict? I don’t know, but google assistant recently started to advertise me the rates for DB Base Metals Double Long (currently at $4.52)… do you also have that? Yeah, this is BDD at The New York Stock Exchange (Arca)…
So while waiting for BDD to prosper, your dose for March 2016 contains the following topics:
- [Watch] TDD – Eat it raw! (Kevlin Henney)
- [Background] Why Cucumber? (Aslak Hellesøy)
- [Learn:SpecFlow] How to structure test automation code with the driver pattern (David Leitner)
- [Learn:SpecFlow] Feature file backgrounds (Gaspar Nagy)
- [Process] Given/When/Then — How to phrase them? (Liz Keogh)
- [Process] Climbing up and down inside the Test Pyramid (Konstantin Kudryashov, Mathias Verraes)
- [Event] Agilia Conference 2016
Read the full newsletter…