spec.rb

# Collaboration test...

describe Client do
  it 'calls a_method on a server' do
    client = Client.new
    server = double 'server'
    expect(server).to receive(:a_method).with(1, 2).and_return 3
    client.do_it(server)
  end
end

# For a server contract test, do you need to write:
# - one test for server.a_method(1, 2)
# - one test that server.a_method(something, something_else) returns 3
# and are they the same test, or separate tests?

In the case where Controller uses Database.sum_open_order_totals(), I imagine that the Controller doesn't actually care about the meaning of "sum", except perhaps for the implied property that sum >= 0. In that case, Controller probably doesn't care about the difference between count_open_orders() and sum_open_order_totals(), so I would let the Controller make the same assumptions about both: return value is a non-negative number. The Database cares about computing the sum correctly, the feature cares about using the sum instead of a count of rows, but the Controller probably doesn't care.

Accordingly, the Controller stubs Database.sum_open_order_totals() to return 0, another non-negative number, to raise an error (if that makes sense) and that's it. If sum_open_order_totals() were really sum_open_order_totals_as_of(date), then I would treat it the same way we did before.

It's an open question whether Database.sum_open_order_totals() needs "sum" to be part of its contract. I would treat this as an implementation detail until I encountered a situation where I felt doubt. What matters most is that sum_open_order_totals() returns a value that is plausible as a sum (>= 0) and raises errors or not as the situation warrants. When we implement Database, we'll write at least one test for sum = reduce (+) 0 (map orders quantity) that puts in 3 orders with quantities 1, 3, 5 and expects a sum of 9. We can leave that as an implementation detail test until the contract test becomes helpful. For example, do we want to make it an explicit part of the contract that Orders have a quantity property? or do we just want to leave implicit the notion that Orders can be "summed" somehow? I prefer the latter until we judge that that's no longer good enough. Doubt, a failing test, or a customer-reported mistake would prompt me to action.

I agree that it feels off to check in a Contract Test that the orders inside the Database are summable (even worse, that they respond to :+! Implementation detail much?!).

Does the Controller care how the Database calculates the sum of the open orders? Probably not. In that case, let Database own the notion of "sum". The Contract Tests for Database might include a few examples of computing the sum of the open orders, but that's useful more for documentation for future clients, rather than for the current Controller.

On To Your React Example

React Component

Add a test for what happens if the stubbed data has the wrong structure. Default values? Blow up?

For a find() method returning at most one item, in general, I want to check this:

• returns nothing
• returns something, good format
• returns something, bad format
  • returns something missing an important property (default value? blow up?)
  • returns something missing an unimportant property (default value? nothing? empty string?)
• raises error

Service object

This appears to wrap a REST endpoint in order to decouple the React component from the data source. In that case:

• data source returns something valid
• data source returns something invalid
• data source returns nothing
• data source blows up

REST Endpoint

Integrated tests with server and/or VCR-style "integrated tests" with real data + fake transport