Comments on Andrzej on Software: Events in acceptance tests

@Andrzej You can have many side scenarios attached...

2011-04-27T00:14:42.817+02:00

@Andrzej You can have many side scenarios attached to one event type. In contrived example after "product:created" you may want to check if a user can recommend a product (but there is no need to check it for every "product:created"). On the other hand you may want to check if product has accurate discount (and you'll probably check this on every "product:created").

For me "practicality beats purity" - advantage of restoring application to previous state means less bugs connected to accidental or implicit state modification in side scenarios.

The workaround you proposed: moving state-changing side scenarios to base scenarios is just about restoring state (or reseting to initial to be precise whereas I propose travelling back to point in time).

@Pawel Other way would be to just trigger each ev...

2011-04-26T23:02:19.772+02:00

@Pawel

Other way would be to just trigger each event only once.

Looking forward to your experiment with database savepoints! It may help, but I'm still not sure if that's the right direction. I'd prefer to be database independent in my acceptance tests.

Nice article. What I also like in this approach is...

2011-04-26T22:52:47.131+02:00

Nice article. What I also like in this approach is the ability to control how many times side scenarios should be executed. We can execute them for every event occurence or just once.

I would probably try database savepoints for maintaining state in a single use-case (e.g. http://dev.mysql.com/doc/refman/5.0/en/savepoint.html)

As I said, it's too early to find answers to a...

2011-04-26T18:19:36.848+02:00

As I said, it's too early to find answers to all questions. The point that bothers you is the crucial one.

It's hard to discuss it without an example.

So far, where we found the need to change the state we created a new base scenario, but it made sense in our case.

I'm not going to try the deep-cloning/transactions solutions :) Sounds scary to me and I want to avoid it.

Editing a product description sounds like a good side scenario although it temporarily changes the state - at the end of the scenario we just edit it to the original version.

It looks interesting. Especially getting rid of fi...

2011-04-26T18:10:58.333+02:00

It looks interesting. Especially getting rid of fixtures/factories without affecting the performance.

Although one point bothers me a bit:

the side scenarios have to leave the application state unchanged

So either you have to make side scenarios read-only or deal with deep-cloning and nested database transactions.
How do you deal with that problem?