4. Implement Test Steps With TestLeft

Before implementing test steps with TestLeft, you need to import the required classes:

You must create an instance of the Driver class as you do this in a regular TestLeft test. The way you do this depends on your test. In our case, we create it in the first test step:

We use the LocalDriver class. This way we access the TestLeft test engine on the local computer. To access the TestLeft test engine running on a remote computer, use the RemoteDriver class.

1. Use the created driver object to run the tested application:

   Java

   Java

   @Given("^I open Notepad$")
   public void i_open_Notepad() throws Exception {
       Driver driver = new LocalDriver();
       TestProcess notepadProcess = driver.getApplications().run("notepad.exe");
   }

   To learn more, see Running Applications From Tests.

2. Run the test. TestLeft should run the Notepad application. After that, the test will stop because the next steps are not implemented yet.

   Note:

   Do not close Notepad. You will use it to implement the next test steps.

When you create a test with TestLeft, you can inspect applications objects, their methods and properties by using TestLeft UI Spy and generate code to get them from the test.

1. Run the TestLeft UI Spy utility.

   • In IntelliJ IDEA, select Tools > TestLeft UI Spy to run the utility.

   -- or --

   • Launch the <TestLeft>\Bin\SmartBear.TestLeft.UI.Spy.exe executable.

2. Configure the TestLeft UI Spy code generation settings. Click on the main toolbar and specify the following settings:

   • In the Languages section, select Java.

   • In The first object section, select Main form / Page. The Process variable name box should specify the name of the variable that contains a reference to the testing process. In our case, it is notepadProcess.

   

   Click the image to enlarge it.

   Click OK.

3. Hold the left mouse on the Pick Object button (the mouse cursor will turn into the target icon (). Drug the cursor to the Notepad window and drop it once a red frame appears around the edit box:

   

   Click the image to enlarge it.

   TestLeft UI Spy will select the object in the object tree. The panel on the right shows the methods and properties of the selected object:

   

   Click the image to enlarge it.

4. To verify that the Notepad window contains no text, use the wText property. Right-click the wText property and select Copy Member Call from the context menu:

   

   Click the image to enlarge it.

   TestLeft will copy the needed code to the clipboard.

5. Paste the code to the method of the next test step:

   Java

   Java

   @Given("^there is no text in Notepad$")
   public void there_is_no_text_in_Notepad() throws Exception {
       TextEdit edit = (TextEdit) notepadProcess.find(TopLevelWindow.class, new WindowPattern(){{
           WndClass = "Notepad";
       }}).find(TextEdit.class, new WindowPattern(){{
           WndClass = "Edit";
       }});
   
       String wTextValue = edit.getwText();
   }

6. You can see that this code cannot find the notepadProcess object. To fix that, you need to make the corresponding object visible for this method. Declare the notepadProcess variable at the beginning of the class:

   Java

   Java

   public class UndoFeatureSteps {
       private TestProcess notepadProcess;
   
       @Given("^I open Notepad$")
       public void i_open_Notepad() throws Exception {
           Driver driver = new LocalDriver();
           notepadProcess = driver.getApplications().run("notepad.exe");
       }
   }

7. Use the Assert.assertEquals method to verify that the property contains an empty string:

   Java

   Java

   @Given("^there is no text in Notepad$")
   public void there_is_no_text_in_Notepad() throws Exception {
       TextEdit edit = (TextEdit) notepadProcess.find(TopLevelWindow.class, new WindowPattern(){{
           WndClass = "Notepad";
       }}).find(TextEdit.class, new WindowPattern(){{
           WndClass = "Edit";
       }});
   
       String wTextValue = edit.getwText();
       Assert.assertEquals("", wTextValue);
   }

1. To implement the next test steps, you need to interact with the edit box. Therefore, you need to make it visible for other methods. Declare the corresponding variable at the beginning of the class:

   Java

   Java

   public class UndoFeatureSteps {
       private TestProcess notepadProcess;
       private TextEdit edit;
   
       ...
   
       @Given("^there is no text in Notepad$")
       public void there_is_no_text_in_Notepad() throws Exception {
           edit = (TextEdit) notepadProcess.find(TopLevelWindow.class, new WindowPattern(){{
               WndClass = "Notepad";
           }}).find(TextEdit.class, new WindowPattern(){{
               WndClass = "Edit";
           }});
   
           ...
       }
   }

2. On the next test step, you need to enter text in the Notepad window. If your IDE supports the autocomplete feature, examine the list of methods available to the object:

   

   Click the image to enlarge it.

   To simulate typing text, we will use the keys method:

   Java

   Java

   @When("^I type \"([^\"]*)\"$")
   public void i_type(String arg1) throws Exception {
       edit.keys(arg1);
   }

   Note that the created method contains the arg1 argument. Cucumber extracts the phrase in quotes from the text of the test step by using a regular expression and passes it to the argument.

3. To simulate pressing hotkeys, we also use the keys method:

   Java

   Java

   @When("^I press \\[Ctrl \\+ z\\]$")
   public void i_press_Ctrl_z() throws Exception {
       edit.keys("^z");
   }

4. Finally, we check that Notepad does not contain any text. Use the Assert.assertEqual method, as we did it earlier:

   Java

   Java

   @Then("^I should see no text in Notepad$")
   public void i_should_see_no_text_in_Notepad() throws Exception {
       Assert.assertEquals("", edit.getwText());
   }

5. Run the test and check if it works. TestLeft will run Notepad, enter text, undo the action and check if the Notepad window is empty.

In behavior-driven development, it is a good practice to refactor the code after the test passes.

In our example, the Notepad application is still running after the test run is over. It means that when another scenario starts, it will run another instance of the application. This may cause errors and performance issues. To fix that, you must close the application when the scenario finishes. To do that, use the @After annotation. Cucumber will run a method with this annotation at the end of each test scenario. Add the following method to the test class:

The final test code is as follows: