Retrospective

Let’s take a step back and discuss what happened here. We’re supposed to learn about integration tests, yet we never touched the integration test after initially writing it. What good is that?

Full disclosure: in initial writing, we did have to go back and clean up the integration test because we had syntax errors and so on. Sometimes we need to fix the assertions after we see what the view looks like.

Integration testing advantages

The integration test offers a few benefits as we write these tests:

• There’s a structure and we know what needs to be done next. This is valuable, although, given the nature of a lot of server-side development, there does tend to be one large gap where the integration test provides the expected outcome but doesn’t give much guidance on how to get there.

• The integration test proves that all of the unit tests work together as a cohesive whole (though we really need to test in a browser when we’re done). One danger cited for unit tests is that it’s easy to see the small details and not the full picture. Having an end-to-end test forces us to describe the whole picture.

• Although the integration test is slow compared to unit tests, it’s often lightning-fast compared to set up the browser integration manually. If we’ve ever tested a form with dozens of required fields, we can see the benefit here.

Looking back at the original test, it was kind of long and unwieldy. We could go back and split out related lines into their own methods.

Or we could try Cucumber, which we will discuss next.