Am 12.07.2013 um 00:17 schrieb Camillo Bruni <camillobr...@gmail.com>:
> > On 2013-07-11, at 11:50, Norbert Hartl <norb...@hartl.name> wrote: > >> I'm playing with Phexampe because I think that in my current project the >> setup of test scenarios will be a huge part of the testing. So do it in a >> structured way reducing doubled initialization procedures should be >> something good. >> I'm just wondering how the state is kept between dependent test cases. A >> Phexample test case returns a value so that >> >> value := self given: #shouldHaveCollectedSomeState >> >> transfers the state from the dependent test case into the current. What do >> you do if the state produced is more complex than a single value? > > I don't remember, but calling multiple times #given:, for each part, doesn't > solve this problem? No, in my case a test needs two participants that communicate with each other. The first test case checks the validity of the request. The second test case checks the validity of the reply. So I need to transfer both communication ends to the next test case. For now I've created a TestScenario class that keeps both parts just so I can return it as a single value. That is not optimal because the number of combinations of objects I need to return together will be quite big and creating a class for each of them is not good. Using TestResources is not optimal either because I need to manually reset them which defeats their purpose. Or I need to have an external class that records the side effects. > >> To be honest I don't understand why in a test case that calls #given: a >> tearDown/setUp cycle is executed between the first and the second test case. >> I think while using #given: I make the second test case explicitly dependent >> on the first. Why should I reset state collected by the first before >> executing the second? > > I think that is one of the possible approximations. Since in general you > cannot say that a testcase is side-effect free (needs teardown) or has some > requirements (setup). > I think side-effect freeness is not the point here. SetUp and tearDown are useful to isolate a single test case. When using #given: you include one test case into another. Meaning the setUp and tearDown needs to surround the combination of both and not each individual. Removing side-effects between the tests is like calling cleanUpInstanceVariables in the middle of a test case. > On the other hand I would rather expect it not to call the setup, especially > in the case where the #given is done on the same class/test suite. > > I only had a look at phexample a while ago, so I don't remember all the > details. I think I will do a try this weekend. Thanks Cami! Norbert
