Let’s say you wanted to run tests with Selenium and then you discovered that they are taking too slow and you just learned that there is a new tool Puppeteer from Google Chrome which allows driving tests faster. If you decided to migrate your tests you would need to rewrite them. What a pain!
That brings us to the first key idea of CodeceptJS. Your tests should not bound to your execution engine. Either you choose Selenium or Puppeteer your tests should look almost the same. But wait a minute… What is CodeceptJS?
If once you feel the limitation of one engine you can easily switch your tests to other. And what about the second key idea, high-level API?
Let’s show the code:
As you see, the test is very easy to read. It can even be understood by the non-technical person.
So for instance, when you need to fill in a field you can specify a name, placeholder or a label of that field and CodeceptJS will find that for you. No need of fragile and long CSS or XPath locators, if your HTML is designed correctly you can match elements by their semantic values:
Really, no promises, no async-awaits? How does it work?
await calls is not a simple task. Or brains are focused on handling promises and not on test scenarios themselves. That’s why CodeceptJS helps us reducing the visual noise. As the tests are linear in most cases we don’t need to know about promises and modern software is smart enough to handle all promises by itself.
So promises are handled by CodeceptJS, providing you with synchronous style experience. However, when you need to interrupt promise chain and get some values out of browser context you still can use
That’s the only reason why you may need async functions in CodeceptJS tests. And the only fact when you should you care about promises.
Writing a Test
First, we need to install CodeceptJS. To start testing we need to choose engine (WebDriverIO, Protractor, Puppeteer, Nightmare) and specify the base URL for all tests. Let’s test something very familiar to every developer here: https://github.com.
First test for `github.com` can start with two lines:
I.amOnPage(‘/’); — opens a website at base url (
pause() — interrupts the execution and switches to interactive shell mode
In this mode, you can work with a browser side-by-side and control it with simple commands. Type `click` and choose an element to see if an element can be located that way and it can actually be clicked. If command passes — add it to your test. If not — try again with the different locator.
So while working in Interactive Shell mode you can write down a complete test.
Also during debug, you can put a
pause() in every line and switch to interactive shell. This feature works even in headless mode. Using Interactive shell is more powerful than debugging your application with breakpoints.
Scenario Driven Tests
Tests are designed to be written as a scenario told by a persona, user who interacts with a system. When executing such tests with `codecept run — steps` command you will see actual step-by-step output and failures when a step fails
In a report, you will always see what step has failed and as a bonus for each failed test, a screenshot of the last page is taken so you can easily review what went wrong and fix it.
As you have seen, CodeceptJS is quite easy to start. Also, CodeceptJS is a mature framework which you can stay with. It provides native support for Page Objects, it has tools to manage data for your tests, supports testing in several browsers (multi-session testing), and because of high-level API, you can even write tests in other languages!
How about some Portuguese tests?
Other translations are supported as well.
CodeceptJS can also execute mobile tests with Appium, run tests in parallel, and… Well, that goes far beyond the introductory post. So you should discover it for yourself.
If you never liked end to end testing — try CodeceptJS which makes testing fun and effective.