Page History

...

This page assumes that you are already familiar with writing basic test cases and asynchronous testing, as well as familiarity with [Before] and [After] methods. Please follow the links provided if you do not feel comfortable with these concepts.

...

• It is easier to write the test this way. If we were to do the adding/removing in the test case itself, we would need to add various asynchronous event listeners and event need to move the success criteria ''out of'' the test case itself and ''into'' an event listener instead. For more on this, compare the two walk-throughs Writing an Asynchronous Test vs. Using Asynchronous Startup.
• It is easier to read. We have just effectively created a test that '''only contains functionality that we are testing'''. Since we are ''presupposing'' adding and removing the custom button to the display list works and not actually ''testing'' it, the test very clearly shows what is being tested without adding code that isn't being tested.

• Wiki Markup

  It is easier to reuse. By using \[Before\] and \[After\] methods, now we have a [[Tests and Test Cases|test case]] ready to test ''any'' functionality on the {{MyButton}} class that needs it to be added to the display list. For example, we may want this test case to test setting the custom style, or test expected behavior if the style is undefined, etc. All we would have to do is add the additional tests without having to worry about re-using the {{UIImpersonator}}, since the {{\[Before\]}}/{{\[After\]}} will do this automatically.

...