aslak hellesoy wrote:
There is persistent state (database) and object state (the object that
serves as a context for a scenario).
I'm not saying that state in and of itself is bad. However, *coupling*
is bad - for maintenance reasons. If the steps share object state (in
@variables) they become coupled.
So why is coupling bad for maintenance? When your step library grows
to several dozens or like in my case, over a hundred, you want to be
able to cherry-pick steps to build new scenarios. If you have coupled
them with object state, you can't do that. These steps will simply not
work unless they're used alongside the steps they are @coupled to.
I agree and have run into this problem, but I have not found a better way in
the environment I am using.
Cucumber starts a transaction when a scenario starts and rolls it back
when it ends (when on Rails).
Nice if you are using Rails, which I am not :) I was curious if anyone had run into the same
problems I do, because I don't use rails, I test directly against the HTTP API, so the database gets
all this test data, you can't use transactions, so the database potentially has this state from
previous Scenarios.
Right now in my Before_Scenario I generally try to clear the database, but that gets hard when it is
relational with a ton of foreign key constraints, and you can't simply delete or truncate a table.
As I said one work around is I create randomly named records every run, so as to avoid collision
with previous data. I wonder if anyone has a better idea?
BTW my Web service is written in Java/Jetty/Spring so I have no Rails/Ruby niceties on that side, so
it is nice to be able to use Ruby in the integration tests.
That is quite interesting, however as I pointed out above there is state
between steps, in the database and in the response.
That's not the coupling kind of state I'm talking about. That's ok.
Ok I think I see the difference, by the state being in the Database or the response variable it does
not implicitly couple steps like an @variable would. But it still requires the database to have been
setup in a certain state by certain preceding Givens or Whens, which is a kind of coupling. But
maybe I am stretching too far on that argument? I still feel coupling is coupling and state is state :)
In Cucumber a Before block has access to the same scope as the steps.
Good that'll make the transition easier I hope.
--
Jim Morris, http://blog.wolfman.com
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
