Utilizing Cuprite with Capybara

What is Serenity Screenplay?   Screenplay is a test automation design pattern used to write readable, maintainable tests; it is part of Serenity BDD. Screenplay uses a model based on the Actors. Every Screenplay test has at least one actor (you can also have multiple actors). You can model scenarios involving multiple users, each with specific Abilities and Interactions. Besides Actors, other important components of Screenplay are Tasks, Interactions, Questions, and Abilities. Tasks and Actions are reusable across different test scenarios, helping minimize code duplication.   To use Screenplay, you will have to add these dependencies into pom.xml file:   <dependency>    <groupId>net.serenity-bdd</groupId>    <artifactId>serenity-screenplay</artifactId>    <version>4.2.34</version>         </dependency> <dependency>    <groupId>net.serenity-bdd</groupId>    <artifactId>serenity-screenplay-webdriver</artifactId>    <version>4.2.34</version> </dependency> Actors An actor represents a user who interacts with the application. Actors have abilities, such as the ability to interact with a web browser. They also perform tasks, interactions, and answer questions to check whether the feature behaves as we expect.   This is how we define an actor and give the actor the ability to interact with a web browser using Selenium WebDriver: final Actor actor = new Actor("User").can(BrowseTheWeb.with(getDriver()));   When writing code with Selenium, it can get a little messy; with a lot of code, it can become hard to read or maintain. For example, it can take a lot of time to figure out the best way to interact with a specific button on a page. With Screenplay, we use actors to perform interaction: Selenium example: getDriver().get("https://testingpage.com/login"); final WebElement username = getDriver().findElement(By.id("username")); username.sendKeys("John-Doe"); final WebElement password = getDriver().findElement(By.id("password")); password.sendKeys("pass123"); final WebElement loginButton = getDriver().findElement(By.id("login")); loginButton.click();   In this example, we can see: Selenium focuses on how you find an element and click on it or type into the field. Code repeats. Screenplay example:   actor.attemptsTo(  Open.url("https://testingpage.com/login"),        SendKeys.of("John-Doe").into(By.id("username")),        SendKeys.of("pass123").into(By.id("password")),        Click.on(Button.withText("Login")) ); OR You can create a separate CommonFields class where you will store common fields: public static final Target USERNAME = Target.the("Username field").located(By.id("username")); public static final Target PASSWORD = Target.the("Password field").located(By.id("password")); public static final Target LOGIN_BUTTON = Target.the("Login button").located(By.id("login"));   And then use it in a test:   actor.attemptsTo(        Open.url("https://examplepage.com/login"),        SendKeys.of("John-Doe").into(CommonFields.USERNAME),        SendKeys.of("pass123").into(CommonFields.PASSWORD),        Click.on(CommonFields.LOGIN_BUTTON) ); In this example, an actor performs a sequence of actions, which describes what the user does, not how it is done. It is readable, reusable, and maintainable. If an element changes, you only need to update it in one place. Tasks A task is a high-level action that an actor performs. It consists of smaller interactions like clicking, typing, etc. We can additionally create a task for login: public class LoginTask implements Task {    private final String username;    private final String password;   public LoginTask(final String username, final String password) {        this.username = username;        this.password = password;    }  public static LoginTask usingData(final String username, final String password) {        return new LoginTask(username, password);    }   @Override   public <T extends Actor> void performAs(T actor) {        actor.attemptsTo(                SendKeys.of(username).into(CommonFields.USERNAME),                SendKeys.of(password).into(CommonFields.PASSWORD),                Click.on(CommonFields.LOGIN_BUTTON)        );    } } And then use it in test:   actor.attemptsTo(        Open.url("https://examplepage.com/login"),        LoginTask.usingData("John-Doe", "pass123") );     In previous examples, we saw how to click on some element or type into the field. Next, we will see more basic interactions: Move mouse Move the mouse on a specific element (for example, you can use it to trigger a tooltip): actor.attemptsTo(MoveMouse.to(CommonFields.LOGIN_BUTTON)); Double click actor.attemptsTo(DoubleClick.on(target)); Right click actor.attemptsTo(RightClick.on(target)); Enter value This will enter a value into a field, first it will wait until the field is enabled, and then clear the field of any current values, before entering the specified value: actor.attemptsTo(Enter.theValue("John-Doe").into(CommonFields.USERNAME)); Upload file Files can be placed in a hard-coded location or stored on the classpath, which is a better solution:   actor.attemptsTo(Upload.theFile(Path.of("test/data/api/files/" + fileName +".extension")).to(uploadField)); Questions When an actor wants to get a specific piece of information from the system, it can be done using a Question. Questions are queries about the application's state. Actors ask questions using the method askFor().   Some of the common Question classes are: Text.of()   final String text = actor.asksFor(Text.of(TARGET_ELEMENT));   This will extract the text of a target element and return the value that you can use for assertion.   When working with table, we can extract data from cells:   final List<String> tableHeaders = actor.asksFor(Text.ofEach(HEADERS)); final List<List<String>> tableRows = actor.asksFor(Text.ofEach(ROWS)); isVisible() boolean isVisible = actor.asksFor(Visibility.of(TARGET_ELEMENT));   This checks whether a UI element is displayed. isDisabled() boolean isDisabled = actor.asksFor(Disabled.of(TARGET_ELEMENT));   This will check whether an element is disabled. Presence.of() boolean isPresent = actor.asksFor(Presence.of(TARGET_ELEMENT)); This checks whether the element is present in the DOM. Conclusion With Serenity Screenplay, you can write clean and maintainable automation tests using Actors, Abilities, Tasks, and Questions. Instead of just writing a bunch of code with Screenplay, your automation code will be easy to read and understand for both QA and developers. It is also important to know that Screenplay doesn’t replace Selenium; they work together. Selenium is the engine that communicates with the browser, and Screenplay is the pattern that makes your tests feel like a story.

Method chaining using Capybara and SitePrism   What are Capybara and SitePrism? Capybara is a Ruby library that is used for automating web pages in concert with an underlying web-based driver. It consists of a user-friendly DSL, used to describe actions that are then executed by the web driver. While the Capybara syntax is very easily readable as-is, it can be improved upon to produce tests that are more DRY. This is where the SitePrism gem comes in - a DSL on top of Capybara, used for implementing the Page Object Model. Out of the box, it comes with predefined classes for many common features of websites, such as pages and sections.  Finally, to produce easily maintainable and completely readable tests, we can use method chaining with these tools. So, on an example of a page consisting of a login form and search function, here’s how we would go about doing that. Setting up page objects Firstly, we need to define the elements that make up the pages in the flow we are testing. Starting with the homepage, we will first define the URL and elements present, using SitePrism’s set_url and element methods: class HomePage < SitePrism::Page     set_url 'https://www.testsite.com'     element :go_to_login, 'some-login-link'     element :search_bar, 'some-search-bar'     element :search_button, ‘some-search-icon' end Notice we are inheriting from SitePrism::Page class, a built-in abstract class within the SitePrism gem. It contains methods used for loading pages as well as checking different attributes, such as if a page is displayed, secure, on the expected URL, etc. After setting up the home page, we do the same for the login page: class LoginPage < SitePrism::Page     set_url 'https://www.testsite.com/login'     element :name, 'some-username-field'     element :password, 'some-password-field'     element :login_button, 'some-login-button' end Defining methods Now that we’ve described these different views on our page, we can, likewise, describe actions that we want to be performed on each. We will add these methods to our page objects, so starting with the Homepage, let’s define a way to access the login form: def go_to_login_page do   go_to_login.click   return(LoginPage.new) end Notice that our method returns a new instance of the LoginPage object. By doing this we avoid having to instantiate a new LoginPage within the test itself.  Then we add the login method to the LoginPage class, as well as a search method to the HomePage class: #In the LoginPage class: def log_in_user(user_name, user_password) do     fill_in(name, with: user_name)     fill_in(password, with: user_password)     login_button.click     return(HomePage.new) end #In the HomePage class: def search_for_something(query) do     fill_in(search_bar, with: query)     search_button.click     return(SearchResults.new) end Method chaining in action Finally, in our spec, we need to require the objects we’ve created and write some tests. In our case, the user should be able to log in and get search results for their query: require_relative './page_objects/HomePage.rb' require_relative './page_objects/LoginPage.rb' describe 'test' do     it 'should login and return search results' do         @app.go_to_login_page           .log_in_user('1337_Jane', 'aLamePassword420')           .search_for_something('Tasty Donuts w chocolate glaze')         expect(page).to have_content('Some results related to the search query')     end end   "Method chaining using Capybara and SitePrism" Tech Bite was brought to you by Amira Džanović, Test Engineer at Atlantbh. Tech Bites are tips, tricks, snippets or explanations about various programming technologies and paradigms, which can help engineers with their everyday job.

Mistakes were made. Let’s acknowledge them The Atlantbh Data Analytics team went through a long and strenuous process of change over the past few years. This evolution, which saw us move from writing reports in Word documents to using complex systems for analysis, was bound to produce mistakes. However, the approach you take in dealing with those mistakes is what sets problem-solvers apart from problem-avoiders. There are essentially two approaches you can take; you can either treat a mistake as your enemy or treat it as your friend. This means you can try to fight it, to hate the fact it appeared in the first place, and let it affect your self and team confidence in a negative manner, or you can acknowledge its existence, try to explain it, i.e. find a pattern in its appearance, and use it to boost your and your team’s learning curve. Mistakes were made. Let’s learn from them When you search for the best ways to solve problems and learn, several things consistently appear. Our team’s quality assurance evolution intuitively followed these rules. First of all, when you are focused on a problem and dive headfirst into it, it’s easy to miss the obvious. We tried to overcome this by designating a team member to verify the report someone else had written. However, an even better way of noticing flaws in an analysis approach or overall logic is by considering multiple perspectives. This is why we introduced a multi-peer-review practice whereby two team members verified a written report produced by a third colleague. Subsequently, the whole analysis flow performed better. Secondly, education practitioners unanimously recommend taking notes. We applied this concept by creating a system where we record a mistake when it appears for the first time, then each time it reoccurs we mark this in the system. Our rule of thumb is: If something erroneous is appearing frequently, there is something wrong with our overall processes. That is the moment when reevaluation and modification of processes occur, with the aim of decreasing the frequency of a given mistake or stopping it from repeating altogether. Mistakes were made. Let’s not repeat them We discussed three steps in dealing with mistakes in a constructive manner: acknowledging them, taking notes, and explaining their occurrence. These three steps are crucial in overcoming the flaws in the process, however, they are simply a means to achieving a goal. In this context, our goal was and still is to stop already detected mistakes from reappearing, which should result in the evolution of our overall process. But first let’s see how we approached the third of the aforementioned steps, explaining the mistakes, i.e. identifying the reasons for their occurrence. We analyzed the overall statistics in the system of mistake tracking I mentioned. Specifically, we sorted the mistakes by frequency, from the most frequent to least frequent mistakes. Then we tried to categorize these mistakes into conceptually similar types. After looking into the results, we found that the majority of mistakes are connected to parts of the process that are routinely performed and that require repetitive work. This represents a less fancy part of the data analytics job, for example, not noticing that some characters are encoded incorrectly, copy-and-paste errors while writing reports, calculation errors, report format errors, etc. In order to overcome this, the whole team took part in creating a system that would cover the widest possible range of steps needed to prepare the dataset for analysis. After identifying those steps, we classified them into groups and created checklists using those groups as a guideline. This system helps us in two major aspects of our work. On the one hand, it prevents mistakes from reoccurring, and on the other, it leaves room for an analyst to perform the more complex parts of the process without being afraid of forgetting those little steps along the way. Finally, this system is used as a means of gathering feedback for new team members, by analyzing comments on skipped or not well-performed steps, written by senior teammates. Also, it can be used as a learning guide, since having an overview of errors already made should help identify one’s own mistake, explain its occurrence, and prevent it from happening again. We hope that these lessons learned will help your data analytics team evolve too, minimizing mistakes and ensuring a higher quality of data analysis.