Pushkarev’s post was related to his open-source library, core-js, but the writing style and the depth of thought he exhibited in his post reminded me of Dostoevsky’s writings. If we look wider, we can see this is not a story of a person but a common mindset built into Russian society.

As an #opensource developer I feel his pain, but as a person, I can’t understand the logic of that person.

All his life problems are direct consequences of his actions but instead of taking responsibility for them, he blames the world and greedy corporations.

His first mistake: he decided to return to Russia. Living there was his own choice. But Russia strikes back. What a surprise!

In his post (which replaced Readme of core-js) he begs for money while writing about how poor he is he wants a “new iPhone for his wife”, so he talks about being entitled to luxury

Also, he mentioned he has 2.5$K on donations and 10K$ on previous contracts

Remember the Raskolnikov from Crime and Punishment? That’s the same character. While thinking of his own greatness he suffers from a lack of money. Denis could drop core-js altogether or maintain it part-time but then he will lose his mission and his vibe as a world Savior

I would not have written that thread if he had not mentioned the war in his post.

(btw, why? As no one asked him about that, really!)

He said that #opensource is out of politics while making a political statement in the next line. It’s double thinking which was also shown in The Idiot novel

Sure, a person like him would think that he is the most victim in the world, so he has no empathy for war victims The difference here: war victims didn’t choose their destiny but Denis did.

War victims were killed, lost their homes, or lose their beloved ones but Denis didn’t

Today over 300 000 such characters are at the war in Ukraine

👿They are ‘out of politics’ but have their political opinion of two evils
👿They blame the West for their miserable lives
👿They don’t take responsibility for their actions

Maybe they are not evil by themselves. Maybe not the worst people. Who knows? They had their families but once they decided to go to kill others

The mix of messianism, victimization, and infantilism turned them into a barbarian horde terrorizing my country.

A significant part of Dostoevsky’s stories is murder and a court. In a novel written by 𝗰𝗼𝗿𝗲-𝗷𝘀 maintainer Denis Pushkarev this section is also presented.

We have a court ruling on Denis’ case with some details I would like to share. So what it was about?

In 2020 Denis had an ‘accident’, as he named it.

Denis was driving a motorbike at 60 km/h In the night when he hit two young women. One of them died. He summarized it as “shit happens”.

Denis blames the victim (they were drunk, had dark clothes, it’s russia, etc), while the court didn’t take his arguments as reasonable:

But did he have a chance to prevent this tragedy? According to the court — yes. The road was straight, and the observability was good, as well as the weather conditions.

Yes, it’s russia if you can be killed at a pedestrian crossing and you get blamed for that!

Denis states that he could not see them as they were lying on the ground. If they were standing he would see them.

A strange argument, as there could be a road hole anywhere. His lights should be able to detect something on the ground. Russian roads are not that good not to take that into account.

Denis tried to blame the victims, as the only victim in this story is himself!

That crazy drunk girl unexpectedly died causing a disturbance in core-js maintaining process!

While Denis accepts his guilt he doesn’t feel regret

Moreover, Denis blames the mother of the victim for a bad upbringing.

That sounds insane to me. Really. I don’t know what to add…

Denis regrets the fact that he is not a privileged person and can’t escape the prosecution.

That’s how that society works. “Oh, I wish I could bribe the policemen and the court”. Those are his thoughts that he thinks are acceptable.

Did you notice how he marked the victims? In quotes. Why?

Correct, he is one TRUE victim of that story.

What a plot, what a character, Mr. Dostoevsky, wake up, you are missing so much here!

So instead of Crime & Punishment that could be a story of Crime & Bribe but because greedy corporations didn’t pay him for open source, that story didn’t happen.

But thanks to the tech community who donated to him, now he has enough money for such cases.

That was a fantastic novel.

But I must say to all people who admire Russian literature: you would prefer not to live inside their novels.

This is not fiction, though. And I’m sorry about the victims.

The final hypocrisy is Denis posting a photo of his son trying to manipulate the reader’s emotions. And asks for money. Somehow, he didn’t post a photo of a girl he killed. But she was someone’s daughter too.

Yet, you donated to him and not to his victims

How can Russians kill so many people in Ukraine? Why don’t they count others’ lives?

That’s why!

🤔 Don’t they have empathy?

🤮 No, it is you who must feel empathy to them

🤔 Why don’t they sympathize the victims?

🤮 Because they are the only victims here

My main point of this post was to show how those things considered to be normal in Russia are not such in modern societies. The Ukrainian community was angry with his statement about ‘two kinds of evil’. Let’s imagine he could put some racist slur into his post. Will he also be considered a good person to send money to?

Denis manipulates the community presenting himself as a self-proclaimed messiah, Internet stands on his shoulders! But in reality, he abuses the bus factor and puts the community at security risks with his behavior.

And the worst thing is that Russian society has the same paradigm. Self-centered people constantly focused on their suffering, accusing others of their miserable lives. So it’s not about Denis at all. It’s about Russian society. It’s rotten.

I enjoyed writing PHP in the past. It was my first web-development language and the first programming language I was paid for. It had its evolution path and even though we can’t say that PHP is stuck in the past, its current development strategy is problematic, and here is why.

I am the creator and one of the maintainers of Codeception Testing Framework and Robo Task Runner. And I know some shit about maintaining PHP libraries.

PHP development nowadays is bumping versions, updating types, and tests, and getting out of cross-dependencies conflicts.

Let’s imagine this situation:

I have my own library MyLib that is expected to support PHP 7.4 and PHP 8+ at the same time.

Meanwhile the coollib package I depend on releases its v2 where it changes the interface of the same function to an incompatible one:

🤓 Client #2 already migrated PHP 8.1 and wants to install coollib 2.0 while

🤠 Client #1 is using PHP 7.4 and can’t move to coollib 2.0

As MyLib author I can either drop 🤠 Client #1 and make a major release not because I introduced some breaking changes but because I bumped dependency of coollib.

Now imagine what happens if coollib has also dependencies… And so on…

But still, I don’t understand why

doStuff(mixed $val)

and

doStuff($val)

are conflicting with each other as they are basically the same function! However, PHP engine treats them differently.

So here are two fundamental problems we have in modern PHP:

🎃 Problem #1: All PHP classes and functions are loaded globally.

🎃 Problem #2: New PHP types are not backward compatible.

If either of these won’t be a problem, we would not get into dependency hell.

Problem #1 was solved in In #NodeJS.

If you require a module it will stay only in the current context and won’t affect the whole application.

So in NodeJS context, different versions of the same library with different signatures of methods can live together.

Problem #2 could be solved on PHP engine level

However, it was not predicted from the start. Using types in the ecosystem and getting into dependency conflict was not an expected outcome of introducing more and more incompatible types into the engine.

Libraries tend to add more and more type changes with breaking compatibility in interfaces every year. Could a community solve this? Yes! Banning types could be an option and staying with PHP 7.0 features only. But that doesn’t sound cool when you know that PHP 7 is not supported anymore and you don’t actually enjoy writing legacy code. Anyway, we can’t force maintainers to keep on old interfaces, right?

So let’s sum up:

While PHP still keeps ugly array_* str* functions from 90s, it breaks compatibility in the ecosystem with every new release.

So it’s neither a modern language nor a stable one.

(sorry, #PHP, you know I love you but I must have said this)

While you can think that everyone can do upgrades every year, it can be automated via Rector and so on… But you can’t run Rector on all your dependencies and bump new versions without the maintainer’s permission.

So you get stuck with the lowest PHP version of any of your dependencies.

That’s how some big projects are still on PHP 7.2..7.4 and can’t get to PHP 8.1.

Upgrading has its cost.

While making a mid-sized framework-based project can be fine to upgrade, large enterprise codebases with custom core and a dozen of dependencies are painfully hard to upgrade

So let’s get back to me, a library author who has a library that just works.

🤓 Client #2 (mid-size) upgraded their app and wants me to upgrade my code as well.

🤠 Client #1 (enterprise size) could not get an upgrade yet and wants to use MyLib.

Should I drop the enterprise client? I don’t want to. Actually, that enterprise client may be supporting MyLib with donations or paying me for consultancy.

As an author of a general-purpose library, I will need to maintain a library with versions for all currently used PHPs. You see, that sucks!

But let’s say, I decided to drop support for all old PHPs.

I say: my lib is PHP 8.1+ compatible!

Client says: ok, we are not going to use your lib, as we won’t upgrade just to use it

I can probably say: how about upgrading to PHP 8.1, as old ones are not maintained and don’t even get security patches!

But the client will reply: we have a team of 100 PHP developers, they are not so stupid as you might think, they also want to upgrade. But we can’t pay them for a month just to make your shitty MyLib be installed on our application.

And that’s the dead end. Upgrading in PHP is very expensive. And it happens for no good reasons. It happens because the PHP engine does not keep the compatibility of interfaces between releases, because PHP libraries upgrade to the most modern features, and because we share the global namespace of loaded classes. As a library maintainer, I need to balance upgrades, create bridges between different libraries and always test for compatibility with other dependencies.

But I’m tired. And I think the majority of maintainers in PHP ecosystem are tired of needless upgrades as well:

taylor otwell 🪐 on Twitter: "Agree with you that PHP breaking changes are being managed very poorly and they often have zero benefit ... / Twitter"

Agree with you that PHP breaking changes are being managed very poorly and they often have zero benefit ...

The State of Browser Test Automation

End to End testing used to follow a very conservative approach. Everyone was using Java/Python/Ruby with Selenium and it really felt that there is no good alternative to this setup. Selenium was everywhere and at some point, it even transformed its protocol to W3C standard. Ok, we have a W3C standard now, so why do we need alternatives?

We always need alternatives and the tech community is great for creating ones! However, before the magnificent rise of JavaScript, no other platforms did provide any sane and popular solution. Nowadays, in the JavaScript ecosystem, we already have 3 alternatives to Selenium and a room is open for new ones! So, in my opinion, switching all browser test automation to JavaScript is a matter of time now. This is a very ambitious statement, but from business, perspective choosing faster and more stable tools over old Selenium in Java should dramatically increase the productivity and outcome for software developers in the test.

The only pain point of switching is JavaScript. Most test automation engineers are trained to work with Selenium in classical backend languages like Java and Python, and switching to a new language or tool can be a problem for them. Test automation was done in Java, all new engineers were trained from scratch for Java and Selenium, and this kept repeating, year by year.

Javascript vs Java vs Python

Ok, but what made JavaScript this popular and why it is winning the battle? At this moment, it’s hard to say it is winning in numbers but it wins in technology. Let me list a few points on what driven JavaScript browser testing evolution:

• JavaScript is already inside the browser. Obvious point. Why to learn two languages if you can use one?
• Electron — a framework that allowed to wrap a browser inside JavaScript engine. It allowed creating a set of Selenium alternatives like Nightmare.js and Cypress.io
• Chrome Dev Tools Protocol — a take from Chrome Development team on bringing their own (non-W3C standard) protocol for controlling browser.

I can also mention the simplicity of a language, it’s flexibility, npm, and the rise of frontend applications as additional points that boosted interest to browser testing in JS. However, unlike traditional setups (Java, Python) JavaScript was never designed for end to end testing.

That’s right.

The problem here is the major feature of JavaScript — asynchrony is absolutely useless, and even dangerous when it comes to testing in a browser.

• All browser commands must run asynchronously (as they always need some time to finish)
• Each test is a list of those commands
• Each test should be linear and predictable

To sum up, we need to run all the commands one by one. Otherwise, we can make tests unpredictable. For instance, if we send 2 commands to the browser: “check element” and “click” we will have no idea which commands finish first and these tests will fail for random reasons all the time. To reduce this flakiness test automation engineers should always keep in mind that all their commands to browser must be synchronized in order to make tests pass. That’s something that doesn’t exist in Java.

Tools for Browser Testing

And now it is time to overview all testing tools over there. Also, I will share their strengths and weaknesses and implementation concerns.

Cypress.io

The most popular Selenium alternative nowadays is brought by a Cypress.io company. Cypress.io was built with the idea that if JavaScript is running inside a browser, we should execute our test within it as well. They built a wrapper on top of a browser using Electron and packed it as a feature full standalone solution. Cypress.io got popular as it was very simple in use, especially for frontend engineers. Working with Cypress.io is as simple as using JQuery in good old days. Cypress.io is faster than Selenium, it is more stable, and can take a benefit from running within an application.

Cypress.io is great! However, before choosing Cypress.io, consider its limitations. Because Cypress.io operates internally within a browser context it doesn’t have access to external features like:

• using iframes
• managing tabs
• managing multiple windows
• uploading files
• downloading files
• sending native keyboard and mouse events

With Cypress.io it is also hard to test interaction with 3rd party websites
and it has a lack of cross-browser support.

Cypress.io works great when it comes to testing single-page applications or components. Cypress.io is loved by developers! But again, the technology behind Cypress.io may not always fulfill the requirements.

WebDriver

When it comes to cross-browser testing, test engineers still prefer WebDriver. Yes, WebDriver is a standard and even the most sophisticated browsers, like Safari or IE are following this standard.

Talking of WebDriver implementations I need to say in JavaScript we have two popular implementations:

• Protractor — which is built on top of the official Selenium library and tries to bring Java-like syntax into JS.
• webdriverio — alternative JavaScript implementation.

As of the beginning of 2020 Protractor is the most popular WebDriver solution, however, it has a lack of maintenance at this moment. I have deep concerns about its future so I wrote a post about it.

webdriverio has a good API, great documentation, cross-browser support, native mobile apps testing support and a rich set of tools built on top of WebDriver protocol.

The technology behind WebDriver has its issues:

• hardened setup — Java, Selenium Server and ChromeDriver (or IEDriver, GeckoDriver) needed. Not as easy to start comparing to Cypress.io
• no access to browser internals — no request mocking, network interception, access to headers, or downloads out of box.
• speed — the way WebDriver operates makes it about 3 times slower comparing to all alternatives.
• strictness — WebDriver is a standard, so it is very strict about what you can do inside a browser. If an element is on a page but a center of element is not visible — you are not able to click that element. If element is moving — you can’t control it.

WebDriver is a great and stable solution with the biggest community. For classical stable setup, WebDriver is still the best on the market. Also, it has rich ecosystem and services like SauceLabs or BrowserStack which help scaling WebDriver tests.

Puppeteer

Puppeteer is like a mix of the best from two worlds — WebDriver and Cypress.io.

Puppeteer is built on top of Chrome DevTools protocol by Chromium developers. So it is using all the API that browser can expose and that’s why it is much more powerful than classical WebDriver. If WebDriver is limited to its standard (all methods should behave similarly in all browsers), Puppeteer is focused around Chrome and Firefox only, so it can drive innovations much faster.

Unlike Cypress.io, Puppeteer gives you true external control of a browser. You can manage tabs, iframes, incognito sessions, network (mocking requests), file uploads, downloads. Almost everything! But its speed is comparable to Cypress.io, yes Puppeteer is really fast.

The only problem with Puppeteer — it is a general-purpose library, and not a test automation solution. So developers usually pair it with Jest or CodeceptJS.

To be correct I need to list the weaknesses of Puppeteer. But I don’t see any technical issues with it. It gives everything possible to you so you could write the most sophisticated browser tests. It is easy to install, has nice API, and very flexible in control. It’s a very straightforward tool, so unlike Cypress, it doesn’t give you nice features like automatic-waiting for elements, or waiting for animations. If you need those features — you need to develop them by yourself.

Puppeteer is great as a technology but has a higher learning curve than Cypress.io and less learning materials than WebDriver. It requires experienced JavaScript engineers who can set it up and build a testing framework around it.

Playwright

We didn’t hear any notable activity from the Puppeteer team for some time. Puppeteer 2.0 was released without any major changes and no real compatibility breaks. It seemed that Puppeteer's development entered the boring stage when only new minor improvements and bugfixes were introduced. We didn’t know that the team behind Puppeteer was working on another project which takes the best from Puppeteer but extends it to Firefox and Safari.

That’s right, officially announced on January 2020 Playwright already looks as a gamechanger. It has polished API from Puppeteer with all its features. Under the hood, Playwright patches Firefox and Webkit (Safari engine) to include its automation API. So this brings a very low-level and very fast protocol for browser control. This approach won’t work with any closed source browser. However, with Microsoft finally switching to Chromium we won’t need any other desktop browser to support in tests.

Playwright team also included several enhancements comparing to Puppeteer:

• reduce the need for timeouts
• better detection for element visibility before interaction

I didn’t have a chance to try it (yet) but looking forward to doing so. I expect Playwright to be highly loved by developers and test automation engineers. The idea and technology look great, as well as the team behind it.

TestCafe

Another great technology with its own pros and cons. TestCafe does a very nice trick — instead of controlling browser on its own, it starts a proxy server that intercepts any calls in a browser and injects their script inside of them.

This is how it works: when you access google.com in a test, the browser is actually opening:

http://192.168.0.110:38475/xVPmF1Kwb/http://google.com/

The real address is a proxy server that sends a request to google.com but appends its own script into every HTML received. This server also starts and closes the browser, however, it doesn’t control a browser when a test when it is running. So, as in Cypress.io, your tests actually work inside a browser (internally).

This solution makes TestCafe the fastest tool with cross-browser support on the market. Indeed, if you don’t need to control a browser, you can use any browser you want! Even Safari, even IE, even mobile Chrome! Every browser can be taken by TestCafe and this will be much faster than WebDriver (because tests are executed inside the browser). The issues with this technology are mostly edge cases which is hard to be listed. Basically, TestCafe should work for the majority of tests, but when it doesn’t work, you won’t have a clear idea why. And no debug tools to help you with that.

TestCafe has a rich set of features, it is fast and has nice community around it. You should definitely take a look at it, if cross-browser support is your primary requirement.

CodeceptJS

Cypress.io, WebDriver, Puppeteer, TestCafe — they are all great. They solve the problem of testing in their own way. However, all those frameworks have their own API and their own syntax. Once we started writing tests we won’t be able to migrate to another engine when we hit an unsolvable problem.

• What if we started writing tests in Puppeteer but then we received a requirement to support Safari in tests?
• We started with WebDriver but we need more browser control that only Puppeteer can give us?
• We started in TestCafe but some tests are unstable
• We started with Cypress.io but our website contains iframes or we need to run tests in two windows.

So here is the idea behind CodeceptJS — a meta-framework for browser test automation. CodeceptJS takes all popular browser driving engines, wraps them and provides you with a unified syntax. Unlike other tools listed in this article, CodeceptJS doesn’t control the browser on its own, it delegates the control to WebDriver, Puppeteer, or TestCafe. This allows CodeceptJS to be focused more on developers' experience. For instance, it brings page objects, step retries, and interactive pause out of the box. CodeceptJS is as simple in usage as Cypress.io but allows you to use different technologies.

While Cypress.io is good for frontend engineers and matches their experience, CodeceptJS focuses more on pure end to end testing. So the test in CodeceptJS looks more like a test plan and not the JavaScript code. So even manual QAs can start working with it learning JavaScript step by step.

Conclusion

I believe this year will be game-changing for test automation. Test automation market is going to hit 30 billion dollars in next years. And JavaScript will drive this growth and the innovation in test automation. Consider switching your browser tests to JavaScript today — but choose the tool wisely, before picking up the most popular Cypress.io or Protractor estimate the alternatives like CodeceptJS, webdriver.io or TestCafe. They can match your requirements better.

When your project contains lots of end-2-end tests you often want to list all tests without actually executing them. This may happen because end-2-end tests can take a long time on execution. And they often require special local environment setup.

So what if you want just to see what tests exist in a project?

Use check-tests CLI tool which can be executed via npx without installing.
Execute it specifying the testing framework you use (protractor in our case) and glob pattern to match test files. That’s all!

npx check-tests protractor "specs/**.js"

It is important to use “ when specifying files pattern, so wildcard patterns could be parsed correctly.

This will list your tests in the following format:

If you write tests in TypeScript, that’s fine. There is built-in TypeScript support, just enable it explicitly with--typescript option:

npx check-tests protractor "specs/**.ts" --typescript

Well done! But check-tests can do much more than just listing tests. It can also be part of your testing process.

Avoiding exclusive and skipped tests

check-tests can notify you on exclusive tests (tests within fit or fdescribe blocks), or skipped tests. When using this on CI you can fail the build when those tests detected.

Add this line before test execution into Travis CI, CircleCI, or Gitlab Runner config (format may differ):

- npx check-tests protractor "specs/**.js" --no-skipped

This way you can always ensure that no commit will introduce new skipped or exclusive tests. Good for your project. Now no one will ever fix tests by making them skipped! 😅

Automating review process with GitHub Actions

If your project is hosted on GitHub you can get even more with check-tests. Because check-tests is also GitHub Action which can automatically review tests in your projects.

With it you can introduce the next patterns in your review process:

• automatically close PRs without tests
• label PR with (or without) tests with a special label
• automatically close PR with new skipped tests

Each PR also will also contain information on added/removed/skipped tests. So you can easily check the quality of the PR.

Setting up check tests for your GitHub project can be done with editing one file. GitHub Actions are free and easy to use. Also, check the sample Protractor config which will help you to start!

P.S. check-tests is part of Testomatio service.
Testomatio synchronizes your Protractor tests with test management CMS. Join our early beta to try it for your project!

Let me elaborate. Cloud Functions in Google (similarly lambdas in AWS) are serverless stateless functions which you pay only for the time of their actual execution. Inside a testing community there was a huge interest towards using them. Indeed, we are launching our browsers just the same way — to launch and stop, and we do not want to pay for the time test is not running! Before this announcement it was pretty hard to make browsers run inside cloud functions, but now Google installs one so we are ready to try it. Can it be the game changer?

Google recommends using Puppeteer library to control the browser. Puppeteer is not a testing framework by itself, so to write and run actual test we will use CodeceptJS testing framework. This one can run tests in various backends, like Selenium, but also has built in support for Puppeteer. If you never met CodeceptJS before, check my previous post: “Effective End 2 End Testing in JavaScript with CodeceptJS”. And today we will try something advanced: running functional test as cloud function.

At first you will need to sign up in the Google Cloud Platform. Even if you don’t have an account there it’s pretty easy to create one, as everyone has Google Account. Google will ask you for a credit card but don’t worry, you will get 300$ for a year to spend, and cloud functions are included into free tier. After the account created you will need to install gcloud command line tool.

Cloud Functions Free Tier includes up to 2 million invocations and 1 million seconds of free compute time per month

And now let’s do some JavaScript stuff. Let’s start by making package.json file including codeceptjs and puppeteer libraries:

{
  "name": "browserTest",
  "main": "index.js",
  "dependencies": {
    "codeceptjs": "^1.3.3",
    "puppeteer": "^1.6.2"
  }
}

Then run npm install . You don’t need to install any other testing framework, like Mocha, because CodeceptJS already brings one on board. It also has assertions baked-in.

Unlike in traditional CodeceptJS installation (which still can be done), we are not able to use CodeceptJS CLI runner here as Google expects pure JavaScript function inside index.js . CodeceptJS has API for creating a custom runner which we will use to run our tests. Copy-paste this snippet into index.js:

In this setup we created configuration for Puppeteer (please note that --no-sandbox option which is required for browser to be launched in cloud) and created a basic reporter. However, we didn’t create any test yet! Tests are standalone files with *_test.js suffix which are loaded from the current directory.

So let’s create one! We will do a basic test around GitHub, that’s why I added into Puppeteer config github.com as base URL value. So a test file, named github_test.js should be pretty simple, however include some interactions and assertions. Here is the one I prepared:

(I use retry() for some commands as the page may not be loaded yet fully)

As you see, you can read the test and understand its output. The syntax is pretty simple, without needless CSS or XPath selectors.

That’s all our test. But let’s get back to our index.js and our main function which is named browserTest (that name will be used by Google). But before we deploy it to the cloud let’s try to run it locally with NodeJS:

node -e 'require("./index").browserTest()'

If you see an output like this, the test is passing and we are ready to push it into the Cloud.

Execute this command:

gcloud beta functions deploy browserTest --trigger-http --runtime nodejs8 --memory 1024MB

On first run you will be asked to enable Google Cloud Functions API. You need to agree on that, and please check that billing is enabled for this project. Otherwise browser won’t be able to reach external websites.

Once the function is deployed it can be executed by the next command:

gcloud beta functions call browserTest

If everything is fine we should see this response after a few seconds:

If not — try rerunning function or look into logs, which Google also provides us with the next command:

gcloud functions logs read

Logs should contain tests output written step by step with assertion failures if there are any. If an error has happened it’s easy to detect where it was. For example, here how the error report will look like in logs:

Finally, let’s switch from the terminal to fancy Dashboard for detailed report on cloud function executions.

Summary

The test is running and starting really fast. However, there are some limitations you need to consider before using Cloud Functions for testing. The strongest one is timeout. By default Google limits execution of cloud functions to 1 minute which can be increased to 9 minutes but no more than that.

That makes Google Cloud not yet ready for complex end to end tests with long scenarios. However, Google Cloud Functions are perfect for healthcheck tests. So you can pick the subset of your tests, and run them from time to time by Google Cloud to ensure availability of your service. If you cover the most basic functionality like login, search, etc and deploy such tests into cloud they will come in handy one day.

Other notable limitations is read-only filesystem, preinstalled Chrome, no control of the system. But the starting time is impressive and the pricing model is very interesting. I hope one day Google will consider increasing the timeout or allow us to spawn multiple functions to run our tests as Cloud Functions.

Running End to End tests as Google Cloud Functions was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are a variety of tools in modern JavaScript which are focused on end to end testing. However, when you need to choose one tool you can take up for a week evaluating pros and cons of different tools. You should consider their features, syntax, maintainability and in the end, you still have doubts if you are doing the right choice. Picking one library makes your tests bound to its implementation, as all end 2 end testing tools in JS have their own syntax.

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?

Introducing CodeceptJS

You guessed it right! CodeceptJS is a testing framework. But unlike other testing tools for JavaScript, it uses most popular JS libraries to drive your browser and adds high-level API on top of them. That’s why a test written for webdriverio could be executed in Protractor or Puppeteer.

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:

If you are experienced JavaScript developer you will notice something unusual in this code. There are no chained calls in the test scenarios. All actions are written one by one as a linear scenario.

Really, no promises, no async-awaits? How does it work?

No-await?

The problem is not about making the things work, the problem is in writing clean maintainable tests. JavaScript is very expressive language, however, maintaining codebase with dozens of then or 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 async/await:

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 (`https://github.com`+`/`)
pause() — interrupts the execution and switches to interactive shell mode

Interactive Shell

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.

More Testing!

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!

No. That would be JavaScript anyway. But you can write tests in other languages than English!

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.

Effective End 2 End Testing in JavaScript with CodeceptJS was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are 3 qualities of a good test:

• Readability
• Stability
• Speed

Make your tests readable at first so they would be easy to follow and change in future, make tests stable to codebase changes, and make them fast for better feedback!

Slides:

• Slides from PhpCE 2017 (Ossa, Poland)
• Slides from Longhorn PHP (Austin, TX)

Video (from PHPTour 2018):

—

I also do trainings and PHP testing consulting. If you want to improve the testing culture of your team, hire developers to do test automation, contact my company SDCLabs sdclabs.com

Slides:

• Slides from TestCon 2017 (Vilnius, Lithuania)

—

I also do trainings and PHP testing consulting. If you want to improve the testing culture of your team, hire developers to do test automation, contact my company SDCLabs sdclabs.com

My slides are avaiable

• Slides from PHPCE 2017 (Ossa, Poland)
• Slides from Bulgaria PHP 2016 (Sofia, Bulgaria)

—

I also do trainings and PHP testing consulting. If you want to integrate Codeception testing framework into your application, and use full powers of it, contact my company SDCLabs sdclabs.com

This talk should have been called “Beyond Unit Testing” as the main purpose of it to show that we need to think about Web Interface tests, REST API tests, developing tests infrastructure and more. The complete overview of tools and approaches available in PHP is listed.

This talk was presented at PHPSerbia 2017:

Beyond Testing PHPSerbia

There are some alternative editions of this talk:

• MageConf 2017 (Kyiv, Ukraine)
• DutchPHP 2016 (Amsterdam, Netherlands)
• J&Beyond 2016 (Barcelona, Spain)
• ScotlandPHP 2016 (Edinburgh, UK)

• Beyond Testing MageConf
• Beyond Testing Dutch PHP
• Beyond Testing J&B
• Beyond Testing ScotlandPHP

—

I also do trainings and PHP testing consulting. If you want to improve the testing culture of your team, hire developers to do test automation, contact my company SDCLabs sdclabs.com