Integration tests are good?

Yes! No. Well, it all depends. The fact is, generally more testing is better. Integration tests are just a piece of the puzzle. I should really take a step back and talk more about the value of testing in general and why everyone should be doing more of it.

Tests are important

When I’m talking to someone about their software, a lot of my questions will touch on their testing. I can gauge a lot about the software and the development team by their answers to the questions about the tests. If they speak confidently and emphasize how important testing is, they probably don’t have a lot of bugs and iterate a lot quicker.

I realize that sometimes the time it takes to write tests feels like it is too prohibitive for the benefit. I’ve written a lot of software without any tests. As I’ve grown as a developer, I’ve come to realize that I actually lose a lot more time when I don’t have good automated tests in place.

Without automated tests, deployment cycles slow down

The larger a software suite gets, the more likely is it that any change is going to break existing functionality, often without you knowing it until it gets to a customer. I’ve been there. Even with a full suite of unit and integration tests, we still have regressions. Without them, I don’t think we would do anything else but fix regressions.

Let’s say you have a really important feature that you want to get out. If you have don’t have good automated tests, you are either going to hurry and develop the feature and then do a lot of manual testing (days or weeks worth, depending on the size of your application and any other features that are going out during this time) to ensure that you didn’t break any existing functionality or you develop it and then put it out in the wild and hope it doesn’t break any existing functionality. You may hear about the broken functionality from customers pretty quickly or it could be weeks later. When you hear about it weeks later, you won’t be sure which feature broke it.

Let’s do this scenario again and assume that you have a good test suite that you are pretty confident will catch any breaks. Between unit and integration tests, it takes about 30 minutes to run. Once the feature is finished with development, you can run your automated tests and have a pretty good degree of certainty that your fancy new feature did not break your already awesome application.

Where integration tests fit

Unit tests are your first line of prepartion when it comes to automated tests. They will test individual functions and units of your application. They are inexpensive to maintain and quick to run.

Integration tests are next. They will test how pieces of your application work together. I’ve written a few articles on them. I do integration tests on web applications. I test things like ensuring that when you add items to your cart, they really get added and in the quantity you expect. That if you remove those items, they really will be removed.

Integration tests can easily be outsourced

For web applications, the great thing is you don’t have to build them yourself. I can build and schedule recurring integration tests for you. I don’t need access to your code. I’ll just test whatever sections you want tested and send you notifications with any failures. You can focus on continuing to develop your awesome features.

I actually would prefer to not know what is happening with the source code. I want to test the application just like a user would use it. I’ll see any bugs that pop up upon normal use quickly.

So. Automated testing is important! I have guides on how to set up your own integrations tests (and some guides about how to do some unit tests) or would be happy to help build automated tests for you if you need or want.

Leave a Reply