QA Automation From Zero-to-Hero with CodeceptJS End-to-End Testing

Supercharge your Dev Team with CodeceptJS in 60 seconds

CodeceptJS is a modern framework for rapidly building End-to-End tests. The framework arms development teams with all the essential tools needed to get started quickly, while also providing the flexibility to supercharge your end-to-end configurations to your heart’s content.

TLDR: Fork my codeceptjs-defaults repo and start building your own tests or…
git clone git@github.com:emmonspired/codeceptjs-defaults.git

Why should you care? Supercharged Automation.

• Agility. Tests should be simple to write and read like a User Story.
• Business Oriented. Balance High Quality with “Getting Things Done”
• Joy. Testing with this framework is more fun, so you’ll write more tests.
• Quality. More tests will lead to more confidence you have in each release.
• Fast Feedback Loop. Fail fast, interactively debug, fix. Rinse & repeat!

Example test from https://codecept.io — Note how easy it is to write and understand the code.

CodeceptJS is responsible for bootstrapping your tests in a NodeJS process, where specified Plugins, Data objects, and Browser Sessions are injected and ready for use within your test suite. Multiple configurations can be used and specified to run tests based on differences between local, dockerized or even remote Continuous Integration environments. You’ll be able to tweak these configuration files when you have a need to, but I’ve gone through some of the trouble for you by making some opinionated decisions that help you can get started quickly.

For end-to-end tests,

It’s everything you’ll ever want.

It’s everything you’ll ever need.

And it’s here right in front of you.

This is where you wanna be!

Core Concepts

• A CodeceptJS Test Suite contains a Featureset for your app under test.
• Each Feature is composed of a group of Scenario definitions.
• Every Scenario represents a logical flow of synchronous Step functions.
• The flow of the Scenario is linear and meant to automate User Steps.
• Every Step is performed by an Actor (I) or through Page Objects.
• A Step is written in easy to understand DSL (Domain Specific Language)
• Our "defaults" for local: WebDriver, Chrome, Selenium-Standalone.
• Our "defaults" for CI: WebDriver, Selenoid, Docker, Jenkins / BlueOcean
• Asynchronous concerns are handled by the framework for you. This improves the readability and maintainability of tests so that you don’t have to worry about “Promise chains” ar “callback hell”.
• Below is an example of a very simplistic test for demonstration purposes:

Example Test code side-by-side with console output

Run the test above from the terminal:qa @navigate-codecept-via-google

CodeceptJS Architecture is Helper Agnostic (sort of)

All helpers share the same API so it’s easy to migrate tests from one backend to other. However, because of difference in backends and their limitations, they are not guaranteed to be compatible with each other. For instance, you can’t set request headers in WebDriver or Protractor, but you can do so in Puppteer or Nightmare. (Quote & Screenshot source attribuition )

Selenium WebDriver handles 95% of our in-house e2e needs. (more info)
That’s what we made the decision to use for our project, and is what is configured in the codeceptjs-defaults repository as well.

Manual testing of modern user interfaces can be extremely tedious. Sure, you could hire a fleet of people to click around your site until you find a way to break it — and there is certainly still a time & place for manual testing — but in order to ensure that you hit all your regression tests before each release, you need a tool like CodeceptJS in your corner. Think of each Scenario written in CodeceptJS as an automaton — the digital equivalent of a Mechanical Turk — that is designed to follow a predetermined sequence of operations over and over again, eliminating the human error in testing. These test will also aid in your ability to prioritize and make sure that the essential “sunny side” (expected passing scenarios), as well as a select “expected failure” tests run.

git clone git@github.com:emmonspired/codeceptjs-defaults.git

When you clone the codeceptjs-defaults project, running the
./sanity-check.sh script will install node_modules dependencies and the selenium-standalone binary so that you can run ./qa @SanityCheck and be quickly on your way.

If this test runs successfully, you have bootstrapped the project folder correctly and you’re off to the races!

Alternatively — if Docker is your thing, I’ve included a Dockerfile along with a dj script (docker / Jenkins simulation) that would package up the CodeceptJs project into a self-contained image and run the tests similar to how they would run in a Jenkins environment: building an image, starting a container, running tests, creating reports, stopping and removing the container. ./config/install-selenoid.sh && ./dj @SanityCheck are the quick way to go from Zero to 60.

As your User Interface grows and becomes more complex, running your e2e tests needs to become part of your daily routine. When you’re just getting started experimenting with CodeceptJS, it’s fine to manually kick off your experimental tests from the command line. I will warn you though! Once you start making e2e testing part of your development cycle, you’ll quickly grow your Scenario suite so large that it’s untenable to run manually.

You’re going to need an automated way of kicking them off and make it part of your CI (Continuous Integration) process. You’ll want to get going with this as soon as possible. The sample codeceptjs-defaults repository has some sane defaults for working with a Dockerfile in a Jenkinsfile. If you’re feeling ambitious, start digging into those configuration files. We’ll be going through each of the project folders and why things are set up the way they are, in the blogs ahead.

Future Blogs Will Cover

• Folder Structure:config|credentials|helpers|jenkinsfiles|tests|pages
• GoogleSheetsData via google-sheets-plugin.js & simple-google-sheets
• EnvironmentData via environment-plugin.js to set up environment props
• qa and api-qa scripts with selenium-standalone
• dj script for use with docker and docker-compose with selenoid
• Jenkins and BlueOcean configuration for Continuous Integration
• Feature examples that can inspire and motivate you to keep building!

Now with 19 years of experience, Dan Emmons strives to make issues that seem complex, overwhelming, or insurmountable more manageable for the Team, and to provide exceptional service that exceeds clients’ expectations. For more information, contact him on LinkedIn or through Emmonspired LLC.