Ensure that Tear Down Steps are always executed. fixes square/KIF#161 #162

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
@blakewatters
Contributor

blakewatters commented Oct 23, 2012

Fixes issue 161 by ensuring that Tear Down Steps are always executed

@puls

This comment has been minimized.

Show comment Hide comment
@puls

puls Dec 7, 2012

Contributor

It's not clear that merging this would help: your tear down steps don't necessarily have meaning if you can't guarantee what comes before them. While it's useful to know how many of your steps are passing, the only thing we can reliably guarantee is that your entire suite passes or fails.

(It's the same reason we include a KIF_EXIT_ON_FAILURE flag, which could stand to be default-on instead of default-off.)

Contributor

puls commented Dec 7, 2012

It's not clear that merging this would help: your tear down steps don't necessarily have meaning if you can't guarantee what comes before them. While it's useful to know how many of your steps are passing, the only thing we can reliably guarantee is that your entire suite passes or fails.

(It's the same reason we include a KIF_EXIT_ON_FAILURE flag, which could stand to be default-on instead of default-off.)

@blakewatters

This comment has been minimized.

Show comment Hide comment
@blakewatters

blakewatters Dec 7, 2012

Contributor

I disagree. I think it entirely depends upon what you are using the steps for. If you are only using them to navigate back to the root of the application or other such configuration that is dependent on UI, then they may well only have meaning if all preceding steps have executed.

I am using them to do things like cancel all NSOperations in queues that may have accumulated during test execution and ensure that there is not any asynchronous activity processing that may impact the execution of the next scenario. If my tear down steps are not executed, then no such guarantee is made and I cannot assess the state of my suite reliably beyond the first failure.

I don't really care about how many of my steps are passing, but I do care about how many of my scenarios are passing and I try to ensure that they are as isolated as possible.

Contributor

blakewatters commented Dec 7, 2012

I disagree. I think it entirely depends upon what you are using the steps for. If you are only using them to navigate back to the root of the application or other such configuration that is dependent on UI, then they may well only have meaning if all preceding steps have executed.

I am using them to do things like cancel all NSOperations in queues that may have accumulated during test execution and ensure that there is not any asynchronous activity processing that may impact the execution of the next scenario. If my tear down steps are not executed, then no such guarantee is made and I cannot assess the state of my suite reliably beyond the first failure.

I don't really care about how many of my steps are passing, but I do care about how many of my scenarios are passing and I try to ensure that they are as isolated as possible.

@blakewatters

This comment has been minimized.

Show comment Hide comment
@blakewatters

blakewatters Dec 22, 2012

Contributor

Note that with the work underway to port KIF to run under SenTest, I expect that the normal setup/teardown support renders this patch moot. And expect it will match the behavior I described

Contributor

blakewatters commented Dec 22, 2012

Note that with the work underway to port KIF to run under SenTest, I expect that the normal setup/teardown support renders this patch moot. And expect it will match the behavior I described

@blakewatters

This comment has been minimized.

Show comment Hide comment
@blakewatters

blakewatters Sep 9, 2013

Contributor

This is unnecessary in a KIF 2.0 world. Closing.

Contributor

blakewatters commented Sep 9, 2013

This is unnecessary in a KIF 2.0 world. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment