..and so are exceptions!

Photo by Martino Pietropoli

Now that I have piqued your interest, it falls to me to explain why I feel that way — especially as there’s a 50:50 chance that you disagree, perhaps even strongly. One thing that I am sure we can agree on is, in programming, there is no avoiding Nulls or exceptions; things go wrong, servers may be down, data may simply not exist, the list of reasons for either nulls or exceptions is about as long as you want to spend thinking of them.

I’m no magician, I cannot give you a solution that guarantees 100%…

Welcome to the second part of the SpecFlowa few tips-n-tricks article. In the first part, we saw how to share steps between files and projects within our solution, but we can do more. I won’t say most tests require data as that will vary depending on the project, but I will say a lot of tests will require data. In this continuation, I will endeavour to share some tips-n-tricks on how to share data between your steps and how to make working with data — single values or tables — much simpler and in a strongly-typed way.

Step Parameters and Data Tables


As regular readers will know, I am a little obsessed with testing at all levels and, whilst the majority of the tests are Unit tests (please see What is Test-Driven Development and What is Test-Driven Development Part 2 to learn more on why that is — assuming you’re not already familiar with the Testing Pyramid), Acceptance tests are crucial to achieving a true, end-to-end, test suite — and SpecFlow is the perfect tool * to achieve this in the C# development world!

*Your opinion may, of course, vary!

Some excellent posts have been created including this one on the basics…

“Encourages simple designs and inspires confidence” — Kent Beck, 2003

Following on from the What is Test-Driven Development article, I thought I’d share more detail on how I structure Unit and Acceptance Tests (System / Integration tests follow the same basic structure as Unit Tests, they just take longer to run). Over the past 10+ years, I’ve tried many different naming conventions and test structures but, overall, I’ve found this style suits my approach best.

I’ll show a simple, but real, refactoring that a good suite of tests will allow me to make in the knowledge that nothing will break…

Photo by Nicolas Thomas

“Encourages simple designs and inspires confidence” — Kent Beck, 2003

Kent Beck is often cited as the creator of Test-Driven Development (TDD) but is more accurately the rediscoverer of TDD. His work on Extreme Programming (XP) (among other things) has helped him promote TDD.

The following is my take on TDD, and why I practice TDD (as well as the rare occasions that I don’t). Like many (if not all!) opinions, not everyone will agree with everything here — I look forward to the discussions this post will inevitably start.

Let me kick off by giving a brief outline of…

Jay Barden

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store