Have you even wondered how you could bring agile acceptance test driven development to the front of your development cycle? Sure ATDD and BDD sound great, but how is it really implemented in the real world? In this episode Jeanine Rust a software architect-developer in test shares with us how to bring acceptance testing into our organizations from the ground up. So listen up and hear how Jeanine put test into Dev-Test-Ops.
About Jeanine Rust
Jeanine Rust is a software architect / developer in test. Throughout her career in the software testing industry, Jeanine has come to value collaboration as one of the primary indicators of a successful team. Over the last few years, she has begun to specialize in acceptance test driven development, using Cucumber and SpecFlow, as an opportunity to partner with everyone from product owners to developers, business analysts to DBAs, and essentially anyone else who shows even the slightest interest. She is currently bringing acceptance testing into a new organization, from the ground up; and diligently evangelizing putting the “test” into Dev-TEST-Ops, whenever the topic arises.
Quotes & Insights from this Test Talk
- ATDD stands for Acceptance Test-Driven Design and Development. Really, what we’re doing is we’re figuring out what the acceptance criteria is before we start developing the code so everybody kind of knows what the end goal is. In my mind, it’s very interchanged I guess with BDD, Behavior-Driven Development. I feel like the similarities are so close. I don’t make a ton of distinction about which is which. I know a lot of process folks will tell you, “Oh, well, there’s … you know, these things are different,” but, in my mind, I treat them almost interchangeably. The big idea here is that we’re trying to figure out the acceptance criteria right at the beginning. We’re using that to drive development in either … whether you call it BDD or you call it ATDD, and then throwing TDD, Test-Driven Development in. In my mind, I see developers doing that as the method for how they develop their code. In my mind, TDD is very unit test-driven and so developers can write their unit test before they develop their code and then, when their unit test passed, they know that they’ve got a successful code written.
- Strangulation is this idea that you’re working with, perhaps, you have a large application to begin with and you’re starting to rewrite sections. You have this large application. You think, “Well, let’s rewrite this smaller sub-module of it.” You start in parallel developing this other, gosh, how to describe it, this other smaller product that’s eventually going to take the place of the big chunk of it. Little by little, you sort of draw out the pieces of functionality and you put it in the new product so you can just sort of gradually make that cut over. You don’t have to have a big line in the sand and say, “Okay, on this date, the whole world is going to change.” You’re just going to go to this new platform. You can do it in a little more gradual way, and that makes it a little bit safer.
- You have these layers of how you build your programs. You’ve got your database layer and that interacts directly with the database. Then you have your middle-tier layer. Ideally, that’s where you would have a lot of your business logic. You would have it just in that business layer and then, up in the UI, you just have your UI concerns. You don’t have a lot of business layers up in your UI, and that makes it really easy to focus in on what you’re testing where because you don’t have this mixture of logic going on.
- It honestly can make or break the whole approach. If there’s that cultural stigma that these are tests and so only this person can do this activity, that makes it really, really hard to implement because you’ve got to have that collaboration. You’ve got to have developers who are willing to say, “Okay, I can see how this is beneficial. I can see what the vision is. I can see how my putting identification tags on the UI elements would be helpful. I can see how making the APIs accessible is helpful.” It’s a full-team sport. Everyone has to participate in it.
- This idea of goldplating, that testing is not goldplating. It’s giving you, it’s starting to grow that safety net right from the very beginning. You do the tests first. You talk about what’s acceptable. You talk about what the risks are and, as you build that, you just give yourself more confidence to be able to move forward because you know what should change next. You’re going to know if there’s a problem right away. Just start right from the beginning and don’t think, “Ah, the tests aren’t needed at this point. It’s too simple. Um, put testing in later.” Just do it all right from the front, I guess.
- I will go back to my favorite point is collaboration. I propose collaboration in any situation. If you want to get ATDD off the ground, I mean it’s a team effort. It’s this idea of talking through what your approach is going to be, how we can use these tests to the highest benefit. I love collaboration. It’s my favorite part of doing any of this is those conversations that come out of asking the questions.
Resources
Connect with Jeanine Rust
- Twitter:@architestgirl
- LinkedIn: jeaninerust
May I Ask You For a Favor?
Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page.
Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.
Test Talks is sponsored by the fantastic folks at Sauce Labs. Try it for free today!