In software development, testing is a vital part of ensuring quality products. However, how to test and why isn’t always clear or in the mind of developers, who may see it as beyond the scope of their job.
To Gaspar Nagy, creator of SpecFlow, testing is a matter of collaboration, constant feedback, and handling overconfidence. To discuss the subject, we asked him to answer our question on the importance of testing, his journey as a software developer, and the tools he designed for implementing BDD testing.
Listen to the full episode or read the edited transcript.
You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.
Introduction
In this episode, Darko interviews Gaspar Nagy, software developer and founder of open-source test automation tools SpecFlow and SpecSync. Specflow is a testing framework meant for implementing Behavior Driven Development (BDD) practices in the .NET software development framework.
SpecSync, for its part, is a synchronization tool to integrate SpecFlow into developer services tools Azure DevOps and project management software Jira. SpecSync is a synchronization tool to integrate SpecFlow to Azure DevOps and Jira. SpecSync is meant for enterprise clients who need more transparency and traceability in their development. To fit into each company’s development processes, SpecSync supports customization.
Gaspar created these tools as part of his views on the importance of testing, seeing himself as a half developer, half tester:
“One of my goals is to make the connection between developers and testers, and development and testing in general, a little bit closer“, he says.
Understanding that testing is often overlooked, he created SpecFlow at the lack of good tooling for integrating BBD practices on .NET.
Behavior Driven Development (BDD) is an agile approach to development processes that emphasizes collaboration between developers and other teams that participate in the product life cycle. BDD involves describing product behaviors in a language that can run automated tests.
In this way, BDD encourages developing in small iterations to obtain valuable feedback. Also, since the system changes constantly, documentation is automatically updated.
As of today, Gaspar is a BDD evangelist. Gaspar argues that BDD, while starting as a topic of small agile companies, has become quite popular in the enterprise sector. He believes that companies turn to BDD because there aren’t many alternatives for transparent and structured testing.
As such, Gaspar is dedicated to helping teams and clients to implement BDD and overcome the challenges test automation comes with.
The need for testing
Gaspar’s road to creating SpecFlow and SpecSync began in the late 2000s. Agile concepts and test-driven development were brand-new and hadn’t reached Europe, where he was located. However, Gaspar discovered and began implementing user stories and scrum for automated testing.
User stories are an agile technique that consists of writing down a feature’s description from the user’s perspective in one or two sentences. Scrum, for its part, is an agile development framework for small teams that consist of breaking down the project into smaller tasks with short deadlines.
But these tools alone weren’t enough. When designing and executing test systems, Gaspar faced different problems: As the tests grew in number and complexity, they became very hard to understand, especially when Gaspar and his team had to come back to them months later. Maintenance, hence, was equally problematic.
Also, if any of these tests failed, he found them hard to fix. Gaspar learned that improving tests meant making them more understandable by clearly indicating what and how they wanted to test. In this regard, Gaspar tried different approaches for documenting testing, including commenting on the code; however, according to him, this approach requires developers too much discipline and is difficult for maintainability.
The solution was Cucumber. Cucumber allows using BDD through executing and validating specifications written in plain text. To do so, Cucumber uses the Gherkin syntax. After familiarizing with Cucumber, Gaspar took its concept and used it to create SpecFlow, Cucumber’s port for .NET.
Listen also: Cucumber Founder Aslak Hellesøy on TDD and BDD
BDD main challenges
When it comes to the common challenges during adoption, Gaspar sees that developers prejudge how necessary testing is: “They think that they’re good enough so that they don’t need a test. And I can partly understand that because I was also growing up in this kind of thinking, and I was considering myself a good developer, generally.
And I was many times surprised that even though I was a hundred percent sure that it works, I was a hundred percent sure that I was thinking it over several times and it was still falling.”
Gaspar’s solution for this problem —which is even more critical when it is held by team key players— is for developers to learn to make room for not trusting themselves.
The other key challenge he sees is ensuring the business as a whole integrates BDD. It is only when the whole product development teams adopt BDD that it shows all its benefits.
In his experience, the earlier you start the BDD process, the better. This is because Gaspar believes that any team starting with BDD is in for doing two demanding things simultaneously: attempting to improve collaboration through a new platform and implementing or improving their automated testing.
The earlier you start the BDD process, the better
-Gaspar Nagy
The business value of BDD
In Gaspar’s experience, it is management that regularly pushes BDD implementation. In the other direction, when teams want to pitch it to their superiors, he understands that it is key to convey BDD as business-driven and explain the real value it provides:
“The value is whether we can provide better coverage, requirement coverage, traceability; better predictions on our progress because we are doing some functional progress here or have fewer production issues because we have a better understanding of the requirements”.
-Gaspar Nagy
Gaspar also acknowledges that BDD can provide benefits in multiple areas, while also helping create a more readable product, which proves valuable when training new hires: “We have a structure testing where our tests are business readable.
So if someone would like to better understand how our system works for this particular feature, then they can make a cool look starting from a test, and through that, they can learn about how the system works.”
What BDD implementation looks like
When acting as a consultant, Gaspar’s approach starts by doing minimal training on what BDD consists of and how it works. He then takes “a user story from their domain, maybe one that they will start to work on next week anyway, and try to analyze the user story with the methods, with the tools that we are using, typically with BDD, try to find rules, try to find examples, try to formulate those examples, BDD scenarios, and try to push it through so that we also get automated tests from that. And then what we are seeing based on this concrete example, of course, we can modify or extend so that there’s a feedback and review process.”
The process continues with other user stories, until learning the different kinds of problems the teams face. After that, they have enough information to produce the first hypothesis to try out as a pilot project. This is the methodology for decoupling the organization’s complexity:
BDD helps deal with complexity during development by helping decouple problems and define smaller achievable goals.
According to Gaspar, this approach is what may delay things when starting implementing BDD, however, once the project has gained momentum, it shouldn’t:
“initially everything is much slower, but it gets faster. And I think, at least, that’s my perception, that altogether a project done with BDD shouldn’t take longer than a project done without BDD”.
The bottom line
Aside from consulting, Gaspar Nagy is writing a book series about BDD along with his colleague Seb Rose. BDD Books’ first two volumes are available on BDDbooks.com: Discovery, which is about structuring requirements the BDD way, and Formulation, on how to write good BDD scenarios.
Additionally, they are currently working on a third book, this one on automation test patterns’ design. You can reach Gaspar through his company’s website: specsolutions.eu.
