Good practice for integration tests for external endpoints of a rails application?

Question

I will keep this up to date, I have a rail application that communicates with other applications, some use SOAP (non-rail applications, of course ...) and others with REST. I do integration tests to make sure my wrapper classes wrappers have the correct mappings and settings. However, they run the default rake test , which makes it slow and fragile. I want to often perform unit tests and integration tests only on request. How do you do this?

What are your preferences regarding such integration testing?

• How deep are you unit test and / or layout?
• Are you copying the answers to all SOAP or REST xml as stubs?
• Do you generally create external endpoint integration tests?

Update Q: How to exclude a test directory while rake test running?

Answer 1

VCR solution.

Answer 2

If you follow what Rspec / Cucumber people offer, then the level of integration is an unacceptable place to mock your data, as in some respects it defeats the goal of the integration / acceptance test. However, you have to mock things like transactions in PayPal, right? In my current project, I came across this a lot, and here are some of the solutions that I am implementing:

• Testing tags that won’t work in specific contexts. In my example, many servers live behind firewalls, and therefore my tests fail if I am at home and do not use vpn. Thus, in the cucumber, I can mark them as @firewall and tell it to run tests that are not marked by the firewall. I am sure that Rspec 2.0 also supports this feature.

• Denial of service requests. Yes, this is probably a bad idea, but I don’t understand how to do it anyway with any predictability. I have a separate test suite that confirms that the services are running, and from my rails application, I assume that they are working correctly. An example of this might be LDAP. And yes, in these circumstances, I usually use the real answer and do something like this. response = double('response') ; response.expects(:data).and_returns('my xml here')

• I think that regardless of the complexity of the system, endpoint tests are really important. I really enjoy the cucumber, it gives me 95% of what I need to do in functional tests, and so I end up writing fewer such tests and most workflow tests.

Answer 3

The exception tests the integration endpoints of rake test and the ability to isolate and run by a rake test:endpoints were allowed only a few lines of code. I must admit, I spent many hours cursing and cursing. There should be more documentation and explanation in the source of the rails. Such Ruby code, as a rule, is not very clear, IMO.

Well, here it is: create your task: lib / tasks / slow_tests.rake

 require 'rails/test_unit/railtie' desc "Runs all endpoint integration tests." namespace :test do #hooks on to the test task through the 'test:prepare' #For details, check the railties gem (v3.0+) lib/rails/test_unit/testing.rake, #look for "task :test" and "namespace :test" TestTaskWithoutDescription.new(:endpoints => 'test:prepare') do |t| t.libs << 'test' t.pattern = 'test/endpoints/**/*_test.rb' end end 

Now I can put my fragile endpoint integration tests into the test / enpoints directory, running them whenever I want (not often)

Note: this assumes a test / block or point.

Answer 4

You should write a thin layer around the external APIs (Facade / Wrapper) and use vcr-gem to "stub" the network calls. You can get more information from my article on rails testing architecture .