[LRUG] Serialising a struct

[Graham Ashton]

On 14 Apr 2014, at 17:25, Stephen Nelson-Smith <sanelson at gmail.com> wrote:

>> this sounds like a potential opportunity to decouple the part of your application that queries AWS from the part that uses the resulting data, "hexagonal" style.
> 
> Yep... that's actually exactly what I've done.  There's a separate class whose responsibility is purely to establish a connection via the AWS gem, and broker data.  The thinking was that I can test and alter what is behind that, as long as the adapter presents a unified interface to the rest of the application.

This sounds like an even stronger argument to just build a struct in your test and to pass it through to the code under test.

While it may appear simpler on the face of it to just let some code you won’t really see serialise stuff and then pass it through to you, your part of the app is now dependent on how the other bit evolves. It’s actually more complicated.

If building the struct seems messy (as it has a lot of stuff that varies depending on how you use it) don’t do that inline. I tend to do this kind fo thing in helper methods. You can create structs that are well suited to each test with optional parameters. I do this a lot:

  def my_struct(options = {})
    attributes = {
      some: ‘stuff’,
      that: ‘is usually there'
    }.merge(options)
    MyStruct.new(*attributes.values)
  end

  test “blah blah” do
    assert CodeUnderTest.new(my_struct(foo: ‘bar’)).works?
  end

I’ve not tested that code (and don’t normally use structs, so it might blow up in your face), but it should illustrate what I’m getting at.

The key benefit of this approach in my view is that everything you need to know to determine what the code is acting on is visible in this test file, rather than being hidden away inside a lump of XML in a fixture.


-- 
Graham Ashton
Founder, Agile Planner
https://www.agileplannerapp.com | @agileplanner | @grahamashton