BDD Archives - Automated Visual Testing | Applitools https://applitools.com/blog/tag/bdd/ Applitools delivers the next generation of test automation powered by AI assisted computer vision technology known as Visual AI. Mon, 13 Feb 2023 16:33:40 +0000 en-US hourly 1 Acceptance Test-Driven Development for Front End https://applitools.com/blog/acceptance-test-driven-development-for-front-end/ Mon, 13 Feb 2023 16:33:40 +0000 https://applitools.com/?p=46338 I first was introduced to Acceptance Test-Driven Development (ATDD) at a meetup run by ASOS technology. I loved the theory and ended up joining ASOS where I was able to...

The post Acceptance Test-Driven Development for Front End appeared first on Automated Visual Testing | Applitools.

]]>
ATDD flow chart

I first was introduced to Acceptance Test-Driven Development (ATDD) at a meetup run by ASOS technology. I loved the theory and ended up joining ASOS where I was able to see it in practice. Working within a cross-functional development team, through pair programming or working at the same time on feature code and test code. This was an amazing environment to work in where I learnt a lot, especially the whole team owning the quality of their software. ATDD encourages QA engineers and developers to work together on implementing the behavioural tests. Meaning edge cases and testers mindset is applied right from the beginning of the development cycle. Behaviour is documented as part of the feature development as well meaning you have live documentation about what was actually implemented.

Gojko Adzic defines ATDD as:

“Write a single acceptance test and then just enough production functionality/code to fulfill that test”

Introduction to TDD
diagram of atdd flow
Flow chart of ATDD

In this article I will aim to distinguish between ATDD and Test-Driven Development (TDD) and also explain the differences between ATDD and Behavioural-Driven Development (BDD). As well, I will:

  • Explain how ATDD fits into your agile testing strategy.
  • Detail the flow of ATDD using a simple example using frontend technologies and how it can be applied for backend.
  • Share the importance of not forgetting about visual changes when it comes to test coverage.

Finally, if you want to learn more about this then you can take my course on test automation university: Acceptance Test Driven Development for the Front End.

My introduction to ATDD

We would create pull requests which included the feature alongside unit, component, and acceptance tests. I was fortunate to be on-boarded onto the team by a brilliant engineer, who walked me through the process step by step. One of those steps was using Gherkin syntax (Given, When, Then) to create the acceptance test scenarios, right at the start of development of a feature. This would allow the QA Engineer to share the Gherkin scenarios with the whole team including the Business Analyst, Solutions Architect, and Developers. Everyone understood and “accepted” the test cases before they were implemented, saving any wasted time and energy.

How ATDD differs from other strategies

The focus of ATDD is on behaviour of the user. Acceptance criteria are always written from the user’s perspective and aim to explain the requirements of the user to be able to be translated into software (this is harder than it is described). The difficulty with writing code is that you can lose sight of the user requirements during the development process. Thinking about design patterns, writing clean functions and classes, and engineering for future scaling considerations. It’s only human to think like this and get lost in the details. Hence, the addition of acceptance tests can help align the code implementation with the acceptance criteria.

TDD vs ATDD

TDD focuses on the implementation of units of code or isolated functions. TDD is used within ATDD as the inner circle (refer to ATDD diagram). For example, where you have a username field on the registration page, the username input tracks changes when the user types into the text box. This may be abstracted within the code to a function which could be tested in isolation. This is an implementation detail which would not concern the user; they just expect to be able to use the input field without concerning themselves with the implementation detail. ATDD focuses on the overarching behaviour from the perspective of the user.

source code editor with 2 windows

BDD vs ATDD

BDD can be used as part of the ATDD cycle to describe the acceptance criteria. BDD describes the process of how business requirements are documented or designed and is often referenced when using Gherkin syntax. The Gherkin requirements can be translated to acceptance tests. The difference being BDD relates to the business phase and ATDD relates to the development phase.

Agile testing vs ATDD

Agile testing is the strategy or practice at which ATDD could be part of. Agile Testing involves testing throughout the software development lifecycle. For example, within a scrum agile environment, you would think about testing requirements through to testing in production. When analysing the test strategy for an agile team I would think about including ATDD as part of the continuous testing as this would enable teams to deliver quickly and with quality.

Example of ATDD in action

As previously mentioned, we are using a registration page as an example. We want to build the username field using ATDD starting with the Minimal Viable Product (MVP), which is the username input which accepts any value – no validation or username duplication checks.

  1. Write the acceptance test for the input box.
  2. Run the acceptance test – which fails.
  3. Write the unit test for the input box.
  4. Run the unit test – which fails.
  5. Implement the MVP username field.
  6. Run both acceptance and unit tests.
  7. Refactor code if required.
  8. Add visual tests for CSS / Responsive design.

At this point, you continue with the loop, adding additional features to the username field such as validation using the ATDD cycle.

mobile phone registration input box
Registration example

Writing your acceptance tests

You can write your acceptance tests using whichever framework or style you wish: Using native programming constructs with plain English test names and wrapping test scenarios in well described statements. Or with the use of a BDD framework which offers gherkin syntax abstraction. I would recommend only using the abstraction if you are communicating the scenarios with business users or, even better, collaborating with them on the scenarios. However, sometimes your test report with clearly described tests can be just as easy to read without the complexities and maintenance costs of using a BDD abstraction.

Using data test ids

As mentioned in the example (1a), a way to make acceptance tests easier when writing the tests before the code is implemented is to default to using data-testids. Primarily decide on a standard for your test ids within your team (e.g. feature_name-{element_type}-{unique identifier}, curly brackets text if required and to make them unique). Then whenever you want to reference an element, you can work out what the data-testid will be based on the standards. Even if you don’t do this upfront, you can easily substitute the id quickly after the component is implemented. The other way to achieve this is to make sure code that is implemented follows HTML Semantics. Therefore, you will be able to reference the appropriate html tag or attribute.

Benefits of ATDD

As described in the example, ATDD means you can make changes to the component in development without risk of breaking other parts of the feature. Additional benefits include:

  • Collaboration of test cases through plain english acceptance test scenarios
  • Acceptance tests part of the definition of done
  • Code coverage doesn’t get added to the backlog after the sprint
  • Developers and Testers working on acceptance tests

Code coverage !== test coverage

As mentioned in the benefits, ATDD helps achieve code coverage at the time of development. However, this does not mean all cases are covered, especially when it comes to considerations like responsiveness and visual elements. This is where visual testing really helps cover those cases not achievable by automated checks. Using Applitools, we can easily configure our automated checks to run against multiple browsers and devices to see how the feature looks. The flexibility to be able to use your testing framework of choice and run the tests in the Ultrafast Grid means you can capture a wide range of issues not covered within functional tests. Again, building in visual testing into the ATDD cycle means that it’s not an afterthought and the backlog doesn’t contain lots of bugs related to responsive design.

different devices

Conclusion

I hope you have takeaways from this blog of how you can engineer this within your team. Hopefully, I have articulated that you can be flexible in how you want to deliver it and it is an approach rather than a defined set of rigid steps. ATDD does require discipline and collaboration to follow the process for every feature. If you want to learn more and walk through the steps using React, Testing Library, and Cypress then head over to my course on Test Automation University, Acceptance Test Driven Development for the Front End.

The post Acceptance Test-Driven Development for Front End appeared first on Automated Visual Testing | Applitools.

]]>
Top New Features of Cucumber JVM v6 https://applitools.com/blog/top-new-features-cucumber-jvm-v6/ Fri, 06 Aug 2021 17:36:51 +0000 https://applitools.com/?p=30218 Behavior Driven Development or BDD is one of the magical terms that many organizations are looking for today. The influence of the BDD methodology has significantly impacted the way the...

The post Top New Features of Cucumber JVM v6 appeared first on Automated Visual Testing | Applitools.

]]>

Behavior Driven Development or BDD is one of the magical terms that many organizations are looking for today. The influence of the BDD methodology has significantly impacted the way the development model works. Its powerful business-driven approach has helped many teams collaborate with different stakeholders to define a better requirement.

One of the well-known tools that help to automate the requirements for the BDD projects is Cucumber. In this article, you will learn about some of the coolest features available as part of Cucumber 6 (cucumber-jvm) & previous versions and how you can leverage them with your automation pack and business discussions.

First, the basics!

For people who are new to Cucumber, the Gherkin language is simple English (or localised) statements put together to make a sensible requirement. It is written in Given-When-Then-But-And format.

The business requirements or the acceptance criteria are written as Scenarios, containing the Gherkin format requirements. Parameterising the scenarios with various combinations are achieved using Scenario Outlines with examples. All these Scenarios are written in a Cucumber feature file in the Cucumber framework.

A sample for a typical feature file is given below:

View the code on Gist.

Rules & Examples:

One of the major features released in cucumber-jvm 6.0.0 is the usage of the Rule keyword. Although it is not a new feature to Cucumber, as it was released first in the cucumber-ruby 4.x and Gherkin 6.0. It’s an optional keyword, but can be very powerful in some business cases.

In general, the Rule keyword will help the team members to think of the scenarios as examples of acceptance criteria or business rules. Examples are different types of scenarios in which the requirement has to be mapped.

This feature will be very useful during the three amigos session, especially for the product owners and to provide better living documentation. The best example for real-time usage can be like this:

View the code on Gist.

Other useful “Keywords”:

Apart from the Rules keyword, many keywords allow the business stakeholders to define the right set of requirements.

Some of them are:

  • Ability: To provide details on the ability of the feature or module
  • Business Need: What is the business requirement for the feature or module
  • Scenario Template: Defines a scenario of a requirement
  • Scenarios: Contains more examples for a defined scenario

The keywords are interchangeable as follows:

High-Level RequirementFeature, Ability, Business Need
ScenarioScenario Outline, Scenario Template
Combinations / ParametersExamples, Scenarios

Though there are new keywords introduced to the Feature file, the way of writing the step definitions remains the same. Cucumber can automatically deduct the scenarios and examples. You can see the step definitions for the above example here.

A sample for Ability, Scenario Template & Scenarios:

View the code on Gist.

Online Cucumber Reports:

This is one of the coolest features available as part of Cucumber to date. You can now view Cucumber reports online with a link generated after every execution. The reports show the test results and act as living documentation. The online reports will be published via the https://reports.cucumber.io site with a unique URL provided in the console output and it will self-destruct in a day, but you can also store it if you wish.

Sample Online Cucumber Report

This feature can be enabled by either:

  • Adding Cucumber.properties file in src/test/resources/cucumber.properties and adding the below code:
cucumber.publish.enabled=true
  • Adding Junit Platform Properties file in src/test/resources/junit-platform.properties with the below code:
cucumber.publish.enabled=true
  • Add an environment variable:
CUCUMBER_PUBLISH_ENABLED=true
  •  From Junit Runner class:
@CucumberOptions(publish = true)

Conclusion

The new features in Cucumber 6 will be of great help to the business stakeholders who like to define their requirements more understandably. This will enable more scenarios to be added for various business needs and for you to perform more collaborative work towards delivering a stable product.

Cucumber Video Demo

References:

  1. Sample code for this Cucumber Demo on GitHub
  2. Cucumber-jvm on GitHub
  3. Cucumber installation docs (java)
  4. Cucumber report collections
  5. Zero Web Security

The post Top New Features of Cucumber JVM v6 appeared first on Automated Visual Testing | Applitools.

]]>
10 Portfolio Projects for Aspiring Automation Engineers https://applitools.com/blog/project-portfolio-for-testers/ Thu, 03 Dec 2020 07:07:24 +0000 https://applitools.com/?p=25007 Angie Jones describes a portfolio of ten projects that help even novice test engineers demonstrate their skills to get the job.

The post 10 Portfolio Projects for Aspiring Automation Engineers appeared first on Automated Visual Testing | Applitools.

]]>

Those looking to break into the test automation field have difficulty doing so because of lack of experience. One way to gain experience is, of course, to study and practice on your own. But how do you demonstrate your newfound knowledge to employers?

Other professionals, such as front-end developers, create portfolios to highlight their skills, and you can do the same as automation engineers!

Here are 10 projects for your test automation portfolio that will help you stand out among the competition.

1. Web browser automation

Web automation is by far the most common and sought-after form of test automation. If you’re looking to break into test automation, this is an absolute must-have for your portfolio.

Be sure to go beyond a basic login flow. Instead, show full scenarios that require your code to interact with multiple pages.

This project should demonstrate your ability to find element locators and interact with various types of elements such as dropdown menus, checkboxes, text fields, buttons, links, alerts, file upload widgets, and frames.

Also, be sure you’re writing clean test code and utilizing design patterns such as the Page Object Model or the Screenplay Pattern.

Sites to practice against:

2. Mobile automation

The demand for mobile test automation engineers has increased over the years as the popularity of mobile apps has soared. Having experience here can certainly work in your favor.

Your portfolio should demonstrate automated testing against both iOS and Android apps. Using Appium to create one project that works for both iOS and Android would be great. Using tools such as Apple’s XCUITest or Google’s Espresso is good as well. But if you go this route, I recommend doing at least two projects (one of each), since each supports only one mobile operating system.

No matter which framework you use, you’ll want to demonstrate the same element interactions as you did in your web automation project, but also mobile-specific gestures such as swiping and pinching.

Apps to practice with; download any of these to use in your project:

3. Visual automation

After making your web and mobile projects, fork them and add visual testing capabilities to them. You’ll quickly see just how much your tests are missing because they weren’t enabled to verify the appearance of your app.

Visual testing is a skill being listed on a number of job postings, and having this skill will really help you shine against the competition.

4. API automation

With the rise of microservices, IoT applications, and public-facing APIs, the demand for automation engineers who know how to test APIs has become substantial. So definitely add an API testing project to your portfolio. (Here’s a free class on how to test APIs to get you started.)

Within this project, be sure to demonstrate a variety of API methods, with GET and POST as a minimum. Use APIs that require parameters or request bodies, and also return complex responses with multiple objects and arrays.

For bonus points, use advanced verification techniques such as deserialization or approval testing. Also, demonstrating how to mock API responses would be a nice bonus.

APIs to practice against:

5. BDD specification automation

Many teams are practicing behavior-driven development (BDD) and automating tests based on the specifications produced. You’ll want to demonstrate your experience with this and how you can jump in and hit the ground running.

For this portfolio project, be sure to not only show the mapping between feature files and step definitions, but also demonstrate how to share state between steps via dependency injection.

Also, be extremely careful when writing your feature files. Long, verbose feature files will hurt your portfolio more than help. Make the effort to write good, concise Gherkin.

6. Data-driven automation

Your practice projects may use only a small amount of test data, so it’s easy to store that data inside the source code. However, on production development teams, you’ll have hundreds or even thousands of automated tests. To keep up with all this data, many teams adopt a data-driven testing approach.

I recommend adding this to at least one of your projects to demonstrate your ability to programmatically read data from an external source, such as a spreadsheet file.

7. Database usage

Speaking of being able to access data from external sources, it’s a good idea to add a project that interacts with a database. I recommend writing queries within your code to both read and write from a database, and use this within the context of a test.

For example, you can read from the database to gather the expected results of a search query. Or you can write to a database to place your application in a prerequisite state before proceeding to test.

8. Multiple languages and libraries

Writing all of your portfolio projects in one programming language is okay; however, automation engineers often need to dabble in multiple languages.

To make yourself more marketable, try using a different language for a few of your projects.

Also switch it up a bit and try a few other automation libraries as well as assertion libraries. For example, maybe do a project with Selenium WebDriver in Java and JUnit, and another project with Cypress in JavaScript and Mocha.

I know this sounds daunting, but you’ll find that some of the architecture and design patterns in test automation are universal. This exercise will really solidify your understanding of automation principles in general.

9. Accessibility automation

Automating accessibility testing has always been needed but recently has become extremely important for companies. There have been legal battles where companies have been sued because their websites were not accessible to those with disabilities.

Demonstrating that you are able to do test automation for accessibility will give you a great advantage when applying for jobs.

You can use the same sites/apps you used for your web and mobile projects to demonstrate accessibility testing.

10. Performance testing

Last but not least, you should consider adding a performance testing project to your portfolio.

Nonfunctional testing such as performance is a niche skill that many automation engineers do not have. Adding this to your portfolio will help you be perceived as a unicorn who really stands out from the crowd.

Presenting the Portfolio

GitHub

Be sure to put all of your projects on GitHub so employers can easily access and review your code. However, be careful to hide secret keys. This will give you bonus points, since it shows another level of maturity.

Website

Create a website that highlights each of your portfolio projects. You don’t have to build the website yourself; you can use common CMS systems such as WordPress to allow you to quickly get your portfolio up and visible.

Each project highlight should include a paragraph or bullet points explaining what you’ve done in the project and the tools and programming language used.

Resume

Include a link to your portfolio on your resume, and feel free to list your portfolio projects under the “Experience” section of your resume.

While this is not traditional work experience, it shows that you are self-driven, passionate, and competent to break into the test automation field.

Interview

During your interviews, be sure to mention all of the projects you have worked on. Draw from your experiences with building the projects to be able to answer the questions. Also brush up on other concepts around testing and development that may come up during the interview.

Good luck!

The original version of this post can be found at TechBeacon.com.

Header Photo by Shahadat Rahman on Unsplash

The post 10 Portfolio Projects for Aspiring Automation Engineers appeared first on Automated Visual Testing | Applitools.

]]>
Where To Learn Test Programming – July 2020 Edition https://applitools.com/blog/learn-test-programming/ Fri, 10 Jul 2020 12:27:00 +0000 https://applitools.com/?p=17380 What do you do when you have lots of free time on your hands? Why not learn test programming strategies and approaches? When you’re looking for places to learn test...

The post Where To Learn Test Programming – July 2020 Edition appeared first on Automated Visual Testing | Applitools.

]]>

What do you do when you have lots of free time on your hands? Why not learn test programming strategies and approaches?

When you’re looking for places to learn test programming, Test Automation University has you covered. From API testing through visual validation, you can hone your skills and learn new approaches on TAU.

We introduced five new TAU courses from April through June, and each of them can help you expand your knowledge, learn a new approach, and improve your craft as a test automation engineer. They are:

  • Mobile Automation with Appium in JavaScript (1 hr 22 min)
  • Selenium WebDriver with Python (1 hr 13 min)
  • Automated Visual Testing with Python (58 min)
  • Introduction to NUnit (1 hr 19 min)
  • Robot Framework (1 hr 1 min)

These courses add to the other three courses we introduced in January through March 2020:

  • IntelliJ for Test Automation Engineers (3 hrs 41 min)
  • Cucumber with JavaScript (1 hr 22 min)
  • Python Programming (2 hrs)

Each of these courses can give you a new set of skills.

Let’s look at each in a little detail.

Mobile Automation with Appium in JavaScript 

Orane Findley teaches Mobile Automation with Appium in JavaScript. Orane walks through all the basics of Appium, starting with what it is and where it runs. 

“Appium is an open-source tool for automating native, web, and hybrid applications on different platforms.”

In the introduction, Orane describes the course parts:

  • Setup and Dependencies – installing Appium and setting up your first project
  • Working with elements by finding them, sending values, clicking, and submitting
  • Creating sessions, changing screen orientations, and taking screenshots
  • Timing, including TimeOuts and Implicit Waits
  • Collecting attributes and data from an element
  • Selecting and using element states
  • Reviewing everything to make it all make sense

The first chapter, broken into five parts, gets your system ready for the rest of the course. You’ll download and install a Java Developer Kit, a stable version of Node.js, Android Studio and Emulator (for a mobile device emulator), Visual Studio Code for an IDE, Appium Server, and a sample Appium Android Package Kit. If you get into trouble, you can use the Test Automation University Slack channel to get help from Orane. Each subchapter contains the links to get to the proper software. Finally, Orane has you customize your configuration for the course project.

Chapter 2 deals with element and screen interactions for your app. You can find elements on the page, interact with those elements, and scroll the page to make other elements visible.  Orane breaks the chapter into three distinct subchapters so you can become competent with each part of finding, scrolling, and interacting with the app. The quiz comes at the end of the third subchapter.

The remaining chapters each deal with specific bullets listed above: sessions and screen capture, timing, element attributes, and using element states. The final summary chapter ensures you have internalized the key takeaways from the course. Each of these chapters includes its own quiz. 

When you complete this course successfully, you will have both a certificate of completion and the code infrastructure available on your system to start testing mobile apps using Appium.

Selenium WebDriver with Python

Andrew Knight, who blogs as The Automation Panda, teaches the course on Selenium WebDriver with Python. As Andrew points out, Python has become a popular language for test automation. If you don’t know Python at all, he points you to Jess Ingrassellino’s great course, Python for Test Programming, also on Test Automation University.

In the first chapter, Andrew has you write your first test. Not in Python, but in Gherkin. If you have never used Gherkin syntax, it helps you structure your tests in a pseudocode that you can translate into any language of your choice. Andrew points out that it’s important to write your tests steps before you write test code – and Gherkin makes this process straightforward.

The second chapter goes through setting up pytest, the test framework Andrew uses. He assumes you already have Python 3.8 installed. Depending on your machine, you may need to do some work (Macs come with Python 2.7.16 installed, which is old and won’t work. Andrew also goes through the pip package manager to install pipenv. He gives you a github link to his test code for the project.  And, finally he creates a test using the Gherkin codes as comments to show you how a test actually runs in pytest.

In the third chapter, you set up Selenium Webdriver to work with specific browsers, then create your test fixture in pytest. Andrew reminds you to download the appropriate browser driver for the browser you want to test – for example chromedriver to drive Chrome and geckodriver to drive Firefox. Once you use pipenv to install Selenium, you begin your test fixture. One thing to remember is to call an explicit quit for your webdriver after a test.  

Chapter 4 goes through page objects, and how you abstract page object details to simplify your test structure. Chapter 5 goes through element locator structures and how to use these in Python. And, in Chapter 6, Andrew goes through some common webdriver calls and how to use them in your tests. These first six chapters cover the basics of testing with Python and Selenium.

Now that you have the basics down, the final three chapters review some advanced ideas: testing with multiple browsers, handling race conditions, and running your tests in parallel. This course gives you specific skills around Python and Selenium on top of what you can get from the Python for Test Programming course.

Automated Visual Testing with Python

The next course we introduced was Gaurav Singh’s course, Automated Visual Testing with Python. In this course, Gaurav goes through the details of using Applitools – either replacing or alongside – coded assertions of web elements for application testing. If you have never used Applitools and you love Python, you will learn a lot about how to use visual validation through this course. An Applitools user will not learn python testing from Gaurav’s course – the Python for Test Programming serves that purpose much better – and then this course helps you with the Applitools syntax in Python. I posted a detailed review of Gaurav’s course in a separate blog post. 

Introduction to NUnit 

Brendan Connolly teaches Introduction to NUnit. NUnit provides a unit test framework for the .NET universe. It started off as a .net port of the jUnit framework for Java. NUnit allows you to write tests, execute them, and report results. If you’re coding in C#, F#, Visual Basic, or even C++, NUnit can help you write tests effectively.

I already went through the first chapter, which describes NUnit. In the second chapter, you install the .NET SDK. I’m on a Mac and figured I was stuck – but Brendan wrote his course from a Mac. You can use Homebrew to install the SDK. Once you have the SDK, you make sure you have a compatible IDE. You can use the community edition of Visual Studio, JetBrains Rider, or VS Code. Lastly in the chapter you set up your test environment.

In Chapter 3, you write your first test. I’m not a .NET person, but the code examples seemed quite similar to Java, so it was easy to follow along.  

Brendan broke Chapter 4 into three parts: basic assertions, constraint model, and advanced options. Basic assertions, or classic model assertions, provide separate methods for evaluating that a single value, array, string, or collection possesses some property (Assert.IsEmpty, Assert.IsNotEmpty, etc.) or compares two or more and validates a comparison (Assert.AreEqual, Assert.IsGreater, etc.).  The constraint model uses a single method, Assert.That, which receives the constraint to test as part of the parameters passed to it.  The constraint model has become standard in NUnit because of its flexibility. Advanced options let you do things like run tests and report on conditions that are problematic but allow the test to continue running – so, instead of terminating a test on a first failure, the test will continue to run.

Chapters 5 and 6 go through structure and organization of your tests. Chapter 7 focuses on data-driven tests. Finally, Chapter 8 dives into test execution and reporting. 

Overall, this course provides a great introduction into testing within your .NET environment.

Robot Framework

Paul Merrill teaches the course on Robot Framework, a test driver written in Python. Robot Framework boasts it lets people with little or no programming experience create test automation and robotic process automation (RPA). Most importantly, its developers made Robot Framework free and easily extensible. If you are using a programming language like Python, JavaScript, Java, .NET, Perl, or PHP, you can implement Robot Framework keywords in your test code.  

For this course, knowing a programming language can help speed learning along. Students need to know how to use the command line to find and run files, as well as how to open, edit, and save text files.

The course will teach you how to:

  • Recognize and create scripts
  • Install Robot Framework and supporting tools
  • Run tests
  • Recognize and use keywords
  • Drive web browsers with Selenium
  • Create test cases

Because Robot Framework depends on scripting, you’ll spend a bit of time learning how to:

  • Read and write steps
  • Understand how the script runs
  • Configure scripts, plus setup and teardown
  • Create and use variables
  • Read log files and reports

This course launched on June 26 on Test Automation University, and I look forward to taking it to learn Robot Framework.

IntelliJ for Test Automation Engineers

Corina Pip teaches this course on IntelliJ for Test Automation Engineers. This course makes sense for anyone asking,

“How does my approach and toolset compare with what other people do?”

Corina explains the details of using IntelliJ IDEA for test automation.  The 12 chapter course takes 3 hours and 41 minutes to complete, and the course covers the full use of IntellJ IDEA. Her first five chapters involve setup and use of IntelliJ. These are:

  • Installation – you can use the paid version, or the free community version
  • Create and import projects
  • Menus
  • Screens
  • Settings

At the end of these chapters, you have a good idea of where to find things in IntelliJ.

Then, Corina jumps into details about using IntelliJ for test and test automation:

  • Create and edit tests
  • Running tests
  • Debugging tests
  • Code analysis
  • Version Control System integration
  • Additional tips
  • Updating and plugins

The course covers lots of detail. I think you will appreciate test contents in Chapters 6 and 7. Chapter 6 – create and edit tests, contains lots of critical testing tasks:

  1. Creating a package and test class
  2. Building the test methods
  3. Creating fields and variables
  4. Calling methods and jumping to source
  5. Auto import class reformat
  6. Renaming methods and variable

Chapter 7 also covers critical testing tasks, including:

  1. Running a package from the project screen
  2. Rerunning tests
  3. Running tests from the editor and configurations
  4. Pin, fixing tests and rerunning

By the time you get through Chapter 10, you’ll know how to link your tests back to your version controls system (Corina shows examples with Git, but you can use your favorite). The last chapters help you see how to use IntelliJ on an ongoing basis, as packages, add-ons, and the entire IDE receive updates periodically.

If you’re not using automation today, this course provides a great framework. If you are using another approach, Corina will give you some way to compare your results with what she does.

Cucumber with JavaScript

Photo by PhotoMIX-Company–1546875

Do you want to learn test programming for behavior-driven development (BDD)?

Gavin Samuels teaches Cucumber with JavaScript. He focuses this course on BDD, Gherkin, Cucumber, and JavaScript.

Gavin’s first chapter covers BDD in detail. He covers the value of BDD to your organization:

  • Improved collaboration
  • A common language for the product owner, tester and developer
  • Silos break down as team members understand each other’s roles and responsibilities
  • The common language builds a shared team understanding of the requirements
  • Examples used in design become artifacts used in development and test

In his second chapter, Gavin covers Gherkin – a syntax for describing a certain behavior. Each entry provides details for an example or scenario involving a  specific feature and condition – followed by a Given/When/Then set of inputs and result (Given state, When input happens, Then act to create a specific result). This chapter contains the guts of the thought process for BDD. Spend time going through his examples, because the more richly you think things through and specify scenarios in Gherkin, the more likely you can create both usable and reusable code.

The third chapter covers Cucumber. Cucumber supports BDD and can execute Gherkin statements Gavin shows how you can use BDD and Cucumber – or misuse it –  in your environment. Gavin lists out the skills you need for the rest of the course:

  • Java (he shows you where to get Oracle Java)
  • JavaScript (he has you install node.js and npm)
  • Webdriver.io – you need some knowledge.
  • Knowledge of regular expressions
  • A text editor

In the last three chapters, you actually use Cucumber to build tests. Chapter 4 shows you how to set up all the code you have installed. Chapter 5 runs through actual test scenarios. And, finally, Chapter 6 shows you how to add visual validation with Applitools.

Python for Test Automation

Photo by Christina Morillo

Yes, you could get a book. Or, you could take a class. And why take just a generic language class when you can learn Python for a specific use – like, say learn test programming with Python?

Jess Ingrassellino teaches the Python for Test Automation programming class.

If you want to learn Python for test automation, take this course. In the end, you can read, understand, and review Python code. What’s more, you can read, write and understand unit tests, write scripts for different types of testing, create and modify Python/Selenium UI tests, understand security scans, and understand accessibility scans in Python.

Her course looks like a traditional programming course. In fact, if you read the titles of her chapters, you would wonder how it differs from any other language course.  Especially in the last chapter, “Inheritance, Multiple Inheritance, and Polymorphism”, which you might think presents itself as just object-oriented detail. But, in fact, her focus on language helps you understand how you can use Python, or work with others who use Python, in your everyday testing.

Each of the chapters incorporates the idea that you might be testing some parts of the code. She incorporates examples as part of the course, so you can see how to create tests yourself – or how to read tests written by others.

While compact, this course covers key ideas in using Python – starting from installing Python and the Pycharm IDE to creating tests to account for inheritance, multiple inheritance, and polymorphism.

Conclusion

As I find myself with more time on my hands, I expect to take these courses really soon. And, I want to learn test programming skills.

I like the fact that I can learn Python for testing – rather than taking a general language course. I take my programming languages like foreign languages – I’d rather learn French so I can find the lavatory now, and explicate the poetry of Guy de Maupassant sometime in the future.

As a recovering product manager, I am looking forward to seeing how BDD helps developers take my product requirements and turn them into development and test code. So, I’ll make time for Gavin’s course soon.

And, finally, I love seeing how other people make use of the tools they prefer for testing, so I can’t wait to take Corina’s course.

Are you looking for other courses? We have over 35 free courses on Java, JavaScript, C#, Cypress, Selenium IDE, Mocha, Chai… find all of them at Test Automation University.

For More Information

The post Where To Learn Test Programming – July 2020 Edition appeared first on Automated Visual Testing | Applitools.

]]>