205: .Net and Integration Testing Pitfalls with James Penning • Test Guild

Integration Testing is often one of the toughest parts of the software development lifecycle–so in this episode we’ll test talk with James Penning of Get-Testy.com about the Top 5 Pitfalls when Writing Integration Tests, some tips for .NET testers, and more testing awesomeness.

About James Penning

James is a Software Test Engineer with a passion for automation. His main goal as a Test Engineer is to build out tools, frameworks, and libraries to enable other Engineers to build out tests easily.

Quotes & Insights from this Test Talk

So I think originally the decision to go with robot framework was made before I I started my company. But I think really what ultimately had a switch away was the number one point that I had in my post is like we just started writing too many tests and it got to the point where we had like a library of probably around 60 to 70000 robot tests and you know some of them were manual some of them were automated but it took days to run the entire suite and it was really fragile and we basically tried to do everything inside of this framework that we probably shouldn’t have done. And so it was a lot of it just built up to it became unmaintainable and it was it was better to kind of just start fresh in a different framework.
The API layer it allowed us to test the components but without using the UI to facilitate that. And so it kind of is more one of those extensions of a unit test where you’re basically integrating these individual units and making sure that when they interact together they are properly handling the data back and forth. But it’s not a full system level test. So you can really try and isolate certain components in the system to try and make it less fragile because a lot of the UI testing that you do you know you have to make sure that the entire system is up and running at its full where with integration tests you might be able to stand up different parts of the system.
So with new development, if you’re writing a lot of business logic and you know you have a lot of complex logic in your methods. Make sure that you really pin that behavior down with a unit test you know and then once that is that is finished then you want to make sure that when you actually integrated in your product you know if actual data is flowing through it how it handles that and then ultimately like if it’s part of a UI component you might want like 1 or 2 functional tests to make sure that that feature is working. And those are all automated tests whereas you still would want to do exploratory testing on top of that to make sure that you know passes the eye test you know where you look at a human is actually using their brain to make sure that something’s working.
I think if you just really try and get people to focus on what the end goal is you know to deliver a quality product. You have to think of what all the steps are that push you to that goal.
If I was to give one piece of advice I would tell that person that when you’re first starting out trying to become a better tester keep your base really wide. Look into maybe being an engineer for a little bit maybe doing maybe understanding how like product management works and brings acceptance criteria to teams. Kind of just become a jack of all trades and really get a wide breadth of roles and responsibilities before you start to really hone in on what you want to do.

Resources

Connect with James Penning

Twitter: @KingJamesPenn
Blog: get-testy
LinkedIn: jamespenning

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!