gistfile1.rb

# I've been thinking about high level testing, and trying to describe behaviour in ways that
# make it easier to add new tests in the future. Using Chromaroma collections as a base,
# here are some thoughts:


# So, starting with the first tests that we might write:
a normal player 
  should not be able to view the collection admin page
  should not be able to create a new collection
  should not be able to edit an existing collection
  should not be able to hide an existing collection

# those are fine, but missing some key information
# - they don't describe any actual behaviour

# so here's some actual behaviour
a normal player 
  trying to view the collection admin page
    should be redirected back
  trying to create a new collection
    should be redirected back
  trying to edit an existing collection
    should be redirected back
  trying to hide an existing collection
    should be redirected back

# lots of repetition there. Can we extract it out?
a normal player
  should be redirected back when trying to
    view the collection admin page
    create a new collection
    edit an existing collection
    hide an existing collection

# better, but still no really meaty behaviour.
# As an aside, it's worth noting that we're actually
# specifying some of the assertions before some of the setup now too. Interesting.
# How would that work?
a normal player
  (setup) create normal player
  (setup) login as player
  should be redirected back when trying to
    (test) check that a redirection happened
    view the collection admin page
      (setup) visit the collection admin page
    create a new collection
      (setup) visit the new collection page
    edit an existing collection
      (setup) create an existing collection (as an admin?)
              visit the page to edit that collection
    hide an existing collection
      (setup) create an existing collection (as an admin?)
              visit the page to hide that collection
              click hide
    unhide an existing collection
      (setup) create an existing collection (as an admin?)
              visit the page to hide that collection
              hide it (as an admin)
              reload the page or something
              unhide it
# hmm.

# a test might describe things in chronological order from someone's perspective. 
# In this case it's the player, but that might not always be true
a normal player 
  should not be able to view the collection admin page
  should not be able to create a new collection
  (given an existing collection) # sometimes a precondition needs to be run before the start of the setup, right?
                                 # it would be cool to be able to inject this at the start of the setup for the 
                                 # subsequent tests...
                                 # seems like this could be ripe for abuse though.
    should not be able to edit it
    should not be able to hide it

# alternatively, you might want to start with all the conditions before 'anything happens'
given an existing collection
  a normal player
    should not be able to edit it
    should not be able to hide it

# We need some more tests - testing behaviour - to trigger some actual implementation
an admin
  should be able to view the list of collections
  should be able to create a new collection
  should be able to edit an existing colleciton
  should be able to hide a collection
  should be able to unhide a collection

# OK, but again we're missing some description of behaviour
# like, what happens when they do create a new collection
# or even, what actually changes from a users point of view when they create a collection
# 
# These lines are quite dense too - viewing a list of collections implies
# that some collections already exist somehow.
Given some existing collections
  an admin
    should be able to view the list of collections
# maybe, or
an admin
  should be able to create a new collection
    and then view that collection in the list of collections
# which is slightly more realistic chronologically, and could be expanded, e.g.
    and then be able to edit that collection
    and then be able to hide that collection
      and then be able to unhide that collection

# each of these steps would need to generate a part of some setup, i.e.
an admin
  (setup) create admin player
          login as admin
  should be able to create a new collection
    (setup) visit collection page
            click on new
            fill in form and click save
    (test) somehow verify that the collection was created
    and then view that collection in the list of collections
      (setup) visit the collection listing page
      (test) that the collection is present
    and then be able to edit that collection
      (setup) visit the colleciton listing page
              click on the link to edit it
              change some of the values and click save
      (test) somehow verify the new values
    and then be able to hide that collection
      (setup) visit the collection listing page
              click hide on the collection
      (test) somehow verify that the collection is hidden
        and then be able to unhide that collection
          (setup) visit the collection listing page
                  click unhide on the collection
          (test) somehow verify that the collection is no longer hidden

# a test might describe things in chronological order from someone's perspective. 
# In this case it's the player, but that might not always be true
a normal player 
  should not be able to view the collection admin page
  should not be able to create a new collection
  (given an existing collection) # sometimes a precondition needs to be run before the start of the setup, right?
                                 # it would be cool to be able to inject this at the start of the setup for the 
                                 # subsequent tests...
                                 # seems like this could be ripe for abuse though.
    should not be able to edit it
    should not be able to hide it
    (which is hidden)
      should not be able to unhide it

# alternatively, you might want to start with all the conditions before 'starting the clock'
given an existing collection
  a normal player
    should not be able to edit it
    should not be able to hide it
  which is hidden
    a normal player  # for this not to be duplication, it needs to be very concise.
      should not be able to unhide it


# or perhaps there are general ways to check behaviour against a particular
# kind of thing
collections:
  should only be manageable by admins # expanded below
  should have their own page
  should be qualified when a player has visited every member
  when qualified
    should appear on player profile
    should appear in journey history


<x> should only be manageable by admins
  a normal player should be redirected back when trying to
    view the admin <x> index page
    create a new <x>
    edit an existing <x>
    delete an existing <x>

# it seems like a lot of the issue is the tension between
# a) wanting to write about the behaviour in a fluid way, and
# b) expressing the setup in the required order.

# it also seems that there's not a lot of reusability in the "steps" that i've written so far,
# but perhaps the benefit comes when we add more tests. Part of the issue is that adding new
# tests can become harder as we try to figure out how to fit new tests and new behaviour into
# the existing ones. The real goal is to make THAT simpler.