Hello and welcome!
Over the past few weeks I’ve been working on my latest AirPair project Lunch Panoply. I plan on continuing with this project, and my current hurdle of saving a response hash into Rails, but I wanted to share some good news. I was just accepted for a developer internship position!
So one of the first things my new employers want me to read up on is integration testing with Rspec and Capybara. Today’s post is an introduction to what I’ve read thus far.
What is Integration Testing?
Here are a couple of snippets from this wikipedia page on Integration Testing.
Integration testing (sometimes called integration and testing, abbreviated I&T) is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing and before validation testing. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.
The wiki page also includes a paragraph on the purpose of an integration test.
The purpose of integration testing is to verify functional, performance, and reliability requirements placed on major design items. These “design items”, i.e. assemblages (or groups of units), are exercised through their interfaces using black box testing, success and error cases being simulated via appropriate parameter and data inputs. Simulated usage of shared data areas and inter-process communication is tested and individual subsystems are exercised through their input interface. Test cases are constructed to test whether all the components within assemblages interact correctly, for example across procedure calls or process activations, and this is done after testing individual modules, i.e. unit testing. The overall idea is a “building block” approach, in which verified assemblages are added to a verified base which is then used to support the integration testing of further assemblages.
In chapter 13 of his book, Noel says that integration tests are the tool of choice in Rails when we want to test any process that spans one or more controller actions.
He also goes on to state that often a bunch of these tests are written up front and serve as either requirements, a development guide or proof of completion. Sometimes integration tests are written after the primary development is done, for the purpose of ensuring that pieces of code that have only been tested separately are actually making the expected communications.
What’s In an Integration Test?
Integration tests import the same assertion modules that are included in controller tests so we receive methods named after HTTP requests, plus one I haven’t seen before. Here is the list of HTTP methods.
xhr method thats new to my eyes, lets see what this method is all about.
It turns out that first off, the HTTP methods send pretend calls and the
xhr method is used for simulating Ajax calls in controller and integration tests.
Here is a quick example from Noel’s book:
The first argument inside the
test 'an ajax call' block represents the HTTP verb, in this case it’s simulating a POST request. The second argument is the controller method, and we know that the controller method typically associated with POST in a standard RESTful Rails controller is the
:create action. The additional arguments match the order of other HTTP mimic methods, in this case calling a
task resource with an
Integration Tests vs Controller Tests
Although similar to controller tests, integration tests have a few differences that stand out between a controller test and itself.
- Integration tests aren’t limited to a specific controller.
- In a controller test, the session is an element of the response and isn’t guaranteed to behave properly in the event of simulating multiple calls.
- Integration tests retain one or more distinct sessions that persist amid different simulated requests.
Use Cases for an Integration Test
Like the wiki quotes at the beginning of this post state, Integration testing is most effective when used to validate interaction between components that are unit tested elsewhere.
And while Cucumber is best suited for cases where a client or other non-developer are approving test scenarios, Integration tests are typically used more as a developer tool. These tools (including Webrat and Cucumber) can also be used for Black-box testing.
Black-box testing can be described as:
Black-box testing is a method of software testing that examines the functionality of an application (e.g. what the software does) without peering into its internal structures or workings.
Typically we can perform this by only interacting with our application through URL requests and evaluating the application’s response.
So in closing, Integration testing should be used to cover any processes in our application that have multiple steps involved, is based on previously created session data, or in some other way crosses over multiple actions.
When written before TDD tests, they can act as acceptance tests where we are looking to determine if the requirements of a contract specification is met. This can also provide aid while test-driving our application’s model or controller layers.
I have a lot more to read on this, and even have a repo to play around with while I learn. If you have any resources that have been helpful to you while learning to write Integration tests with capybara and Rspec, feel free to leave a comment.
Lastly, I have an AirPair scheduled for Thursday, so I’ll have more to write about Lunch Panoply and saving a web service’s response hash into Rails very soon!
Categories: Ruby on rails