Outside-In Testing

Learn how to use a high-level test to guide you through the requirements for a new feature or change. Ben and Joe discuss the benefits of starting with an integration test, how to descend through the layers until you find the unit which needs chan...
This is a companion discussion topic for the original entry at https://thoughtbot.com/upcase/videos/outside-in-testing

I loved this episode! There’s always lots of little goodies when you guys are doing live coding sessions.

Is there a resource in Upcase somewhere that talks about FactoryGirl vs mocks/stubs in tests? It looks like you generally use factories in integration tests and mocks in the unit tests, but is that the standard practice? Hopefully I’ll have the time to go through the testing material here this month.

Quick question regarding the outside in approach @jferris mention that you write an integration test for the entire UI. What would guys use if you are developing an API, how the integration test will work in this case will you still use rspec feature files or just will directly make an integration test against the service layer?

Thanks in advance,

Sometimes what I feel that I have integration tests that are almost exactly the same as my unit tests. For example, I implement a search feature, so I start with integration test by setting some data to be found and some to be not, then do a search, after that I expect the found records on the screen. When I implement search method in my model, I almost do the same thing for data setup and expectation, so I end up duplicate the test in my model. So every time we change the search logic or the order we almost change in both places. So what do we do about it? /cc @jferris @benorenstein

@Rafael_George, I have taken to use a request folder instead of a feature folder. If you don’t have the iOS on Rails book, you can view the sample here which shows how thoughbot may test their APIs. http://thoughtbot.com/ios-on-rails-sample.pdf

How I’d integration test an API depends on how the API is meant to be used.

For example, if the API is used by a rich JavaScript client (Backbone, Angular, Ember), I’d test it through that UI.

You can use RSpec’s request specs to test individual actions from an integration perspective.

Another approach I’ve used is to make a fake client object with high-level methods for actions clients might take, and implement those actions using rack-test.

@frank_west_iii Thanks; I’ll check that out.