It is common for web applications to interface with external services. When testing, since depending on an external service is very fragile, we end up mocking the interaction with such services. However, once in a while, it is still a good idea to check if the contract between your application and the service is still valid.<\/p>\n
For example, this week we had to interact with a SOAP service<\/a>, let’s call it Since this API is simple, it is very easy to mock the client whenever it is required by our application. On the other hand, we still need to verify that the integration between However, since this is actually contacting the SOAP Service, it may make your test suite more fragile and slower, even more in this case, in which the SOAP Service responses take as long as kitten’s staring contests.<\/p>\n One possible solution to this problem is to make use of filter tags to exclude the SOAP integration tests from running, except when explicitly desired. We could do this by simply setting:<\/p>\n Then, in your Now, running your specs will by default skip all groups that have Notice that filter mechanism is similar to how we enable JavaScript tests when using Capybara. This means that, when using Capybara, you could also run all JavaScript tests in your app via What about you? What is your favorite RSpec trick?<\/p>\n","protected":false},"excerpt":{"rendered":" It is common for web applications to interface with external services. When testing, since depending on an external service is very fragile, we end up mocking the interaction with such services. However, once in a while, it is still a good idea to check if the contract between your application and the service is still … \u00bb<\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[183],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/3147"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=3147"}],"version-history":[{"count":9,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/3147\/revisions"}],"predecessor-version":[{"id":3160,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/3147\/revisions\/3160"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=3147"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=3147"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=3147"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}KittenInfo<\/code> (why would someone provide kitten information via a SOAP service is beyond the scope of this blog post). We only need to contact one end-point of the KittenInfo<\/code> and it is called get_details<\/code>, which receives a kitten identifier and returns kitten information:<\/p>\n\nKittenInfo::Client.new.get_details(\"gorbypuff\")\n<\/pre>\n
KittenInfo<\/code> SOAP service and our application works correctly, so we write some tests for it:<\/p>\n\ndescribe KittenInfo::Client do\n it \"retrieves kitten details\" do\n client = KittenInfo::Client.new\n details = client.get_details(\"gorbypuff\")\n details[:owner].should == \"tenderlove\"\n end\nend\n<\/pre>\n
\ndescribe KittenInfo::Client, external: true do\n # ...\nend\n<\/pre>\n
spec_helper.rb<\/code>, just set:<\/p>\n\nRSpec.configure do |config|\n config.filter_run_excluding external: true\nend\n<\/pre>\n
:external<\/code> set to true<\/code>. Whenever you tweak the client, or in your builds, you can run those specific tests with:<\/p>\n\n$ rspec --tag external\n<\/pre>\n
$ rspec --tag js<\/code> or all non-JavaScript tests with $ rspec --tag ~js<\/code>.<\/p>\n