Unity Integration Test 02

In this test, we are going to learn how to reuse the code to speed up our development session.

We are going to implement the requirement: “Pressing  the “When I press the button “Delete” with the object in the scene, I expect to destroy the object.

The scenario for this test is:

  • Given there is a cube in the scene called “object for test”
  • When I press the button “Delete”
  • Then the software has to destroy the object named “object for test”.

We can see straightaway that the first step is actually what we have already done during the first test. The “Given” step could be implemented using the methods Given, When and Then from the first test scenario. The scenario could also be written in this way:

  • Given the software is just started and waiting for an input
  • and I press the button “Create”
  • and an object named “object for test” appears on the scene
  • When I press the button “Delete”
  • Then the software has to destroy the object named “object for test”.

It could be implemented by adding a new attribute “Given” to the previous “When” and “Then” methods so that we can also have them in the “Given” combo box:

[When("I press the button \"Create\"")]

[Given("I press the button \"Create\"")]

  public  IAssertionResult PressTheButtonCreate()
   {

[...]

[Then("an object named \"object for test\" has to appear on the scene")]

[Given("an object named \"object for test\" has to appear on the scene")]

   public IAssertionResult TheNewObjectAppears()
   {

[...]

Using this feature, the methods that were once visible only in the When and Then combo boxes are now visible in the Given combo box so that we can reuse them. Unfortunately, we are losing the legibility of the scenario.

Fortunately, there is another cleaner way to do this: using the [CallBefore] attribute.

 

   [Given("There is a cube in the scene called \"object for test\"")]

   [CallBefore(1, "StartedAndWaitingForInput")]

   [CallBefore(2, "PressTheButtonCreate")]

   [CallBefore(3, "TheNewObjectAppears")]

   public IAssertionResult ThereIsACubeInTheScene()

   {

       return new AssertionResultSuccessful();

   }

 

The [CallBefore] attribute tells the framework to execute the methods indicated by the string parameter before executing the method ThereIsACubeInTheScene(), in the order indicated by the first numeric parameter. In this case, we have just made a step method using three existing step methods. The main method itself has nothing to do because the other methods make all the job. Every method in the [CallBefore] stack returns its IAssertionResult object: the result of the call chain is the outcome of every single execution so that if there were a failure in the call chain, it would be correctly interpreted by the BDD Framework. For this reason, the main method "ThereIsACubeInTheScene()" can just return a successful state. Coding the test in this way or in the first way is exactly the same for the framework, but we are saving the scenario legibility.

 

Q: Do I have to put only methods from the same scenario step in the CallBefore attribute?

No, you do not have to. In the CallBefore attribute, you can choose every step method you have in your class.

 

Q: Can I use ordinary methods in the CallBefore attribute?

No, you cannot. If you want to call conventional C# methods, just do it in the body of the method you are coding.

 

Q: Can I use step methods from another BDD Component in the CallBefore attribute?

No, you cannot. If you take the decision to develop another BDD Component, mainly it is because you want to keep the code clear, but you can, of course, use the inheritance to bring those step methods in your class. Keep in mind that using the inheritance you are going to see all the step methods coded in the base class on the combo boxes: this behaviour could be wanted or not. Please, read the chapter “BDD Extension Framework Guidelines” for more information.

 

Q: I cannot see my “When” methods in the “Given” combo boxes, but I want to use it. How can I do it?

It is because every combo box filters only the right type of method. In the “Given” combo box you can only see the methods with a [Given] attribute.

 

Sometimes the same code you wrote for the “When” and “Then” methods for a previous scenario are useful for building the first steps of a new scenario. In this case, you can add another attribute, different from the original one, for indicating that you are going to use the method in another Step Type. Usually, the colloquial sentences in the scenario should be a little different so that you have to write the right sentence for the new scenario Step Type. Keep in mind that only one attribute of the same step type is allowed for each method.

 

Back to: Unity Integration Test 01 Read next: Unity Integration Test 03

 

© 2017 Hud Dimension. All Rights Reserved.

Search