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? 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'm a bit reluctant to create new classes for all collected state scenarios so that I can return them properly from one test case to another. Any ideas? thanks, Norbert
On 2013-07-11, at 11:50, Norbert Hartl <norbert@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?
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). 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.
Am 12.07.2013 um 00:17 schrieb Camillo Bruni <camillobruni@gmail.com>:
On 2013-07-11, at 11:50, Norbert Hartl <norbert@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
participants (2)
-
Camillo Bruni -
Norbert Hartl