I like to work with managers who get their hands dirty to have something done, instead of asking someone to do the work.
Managers that exist to manage people shouldn’t be necessary for mature and autonomous teams.
Think about it. If there’s no one to perform the work, what’s the point of having a people manager? In the end, there’s no one to manage.
On the other hand, if there’s no manager, but the people needed to perform the work are there, it can still happen.
I imagine that people managers won’t like reading this post (if they’re ok being in their comfort zone). But I also think that this should be an opportunity for them to re-invent how they work to be still valuable to their teams.
I prefer to work with leaders instead of managers, people who inspire me.
So, if you’re a people manager, I have one favor to ask you, become a leader and lead by example.

Before writing this content, I was reading about software composition, and I had this insight.

I was reading the Elements of JavaScript Style chapter of Eric Elliott’s Composing Software book, and then I thought, how lucky I am to keep open-source projects, such as the protractor-helper, or my website, to name a few.

Such projects allow me to put into practice new knowledge acquired day-after-day, during study hours, to be ready when similar problems arise in work projects.

When the protractor-helper started, all the code was in a single file. Nowadays, the project is better modularized, tested, as well as much better documented. 😀

My website is an example of my experiments with Next.js. There’s a lot to improve, but that’s where the fun lives, after all, it’s my project, which I have total freedom for refactoring.

Besides, in several other side-projects, I have the chance to apply modern DevOps practices, such as continuous integration, automated tests, and even the so-called continuous delivery.

I believe that “practice makes perfect,” and nothing better than practicing on your projects to obtain such proficiency smoothly.

Also, it is grateful that several other professionals and even organizations use some of these projects; this is priceless!

And you, how do you practice your craft? Leave a comment.

Curiosity: this blog was originally written in Portuguese, and you can find it here.

👋😉✌️

Now with type definitions in the functions’ signatures

It is with great pleasure that I present you with the newest version of the protractor-helper library, which now provides a better experience for its users with type definitions in the functions’ signatures.

As of version 4.1.1, if you use the Visual Studio Code editor (or some other with TypeScript support), after importing the library into your test file, when you type something like helper.click(), you will be presented with the parameters that such a function expects, what types such parameters should have, which are mandatory and which are optional, in addition to the return of each function.

Let’s see some examples.

Notice the tooltip displayed, which provides the following information about the scrollToElement method.

The first argument we must pass is an element (elem), which is of type ElementFinder, and such an argument is mandatory.

The second argument we can pass is a timeout in milliseconds (timeoutInMs), which is optional. It is possible to identify that the argument is optional due to the question mark (?) before its type definition, which is a number.

Also, it is possible to notice that such a function returns a Promise.

Let’s look at another example, which expects more arguments.

In the case of the waitForTextToBePresentInElement method, the first argument is also an element (elem) of type ElementFinder, which is mandatory.

The second argument is a text, which is also mandatory and is of type string.

The third argument, as in the previous example, is a timeout in milliseconds (timeoutInMs), which is optional and is of the type number.

Finally, see that this method also returns a Promise.

Now, let’s look at the example of a library method that can be used to perform an assertion.

Note that the isCurrentUrlDifferentFromBaseUrl function does not take any arguments, and returns a boolean, that is, a positive (true) or negative (false) value, which can be used to make an assertion.

Finally, let’s look at a function that expects only an optional argument, and that has no return.

Note that the setTimeout function has only one argument, which is a number, and that argument is optional.

Also, such a function has no return, which can be perceived by the void return, which means the absence of return.

Ah, the examples presented in this post can be found on GitHub through the following URL: https://github.com/wlsf82/sample-protractor

If you are already a user of the protractor-helper library, update it to the newest version (4.1.1) and take advantage of this new functionality.

And if you write tests with the Protractor framework and still don’t use the protractor-helper library, what are you waiting for? Run npm i protractor-helper -D and install it as a dev dependency on your test project.

This post was originally published in Portuguese, and it can be found through the following URL https://talkingabouttesting.com/2020/04/29/lancamento-do-protractor-helper-versao-4-1-1/.

Talk to you next time, and good testing! 👋

Release of protractor-helper version 4.1.1 was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Development, test, performance, staging, canary, production…

I have a theory (and some experience) that having fewer environments in the software ecosystem is better than having more of them.

It’s a common practice in many software projects to have:

• The development environment — also known as the developer’s computer
• The development integrated environment — a remote environment used by developers to have their code integrated so that they can check if they broke the code of someone else, or if someone else broke their code
• The test environments — environments used for manual and/or automated tests
• The staging environment — used for acceptance testing before pushing new code to production
• The canary environment — a special kind of environment used to test new features with a small set of users (commonly used to test things internally before reaching the broader audience)
• The production environment — the environment that our users really use

Some might argue that having all these environments is a good thing. I say it’s not.

The more environments you have, the more problems you have to deal with.

Tell me. Has it never happened to you that a specific bug would only occur in a particular environment, but not in all others?

And have you never experienced an issue that was caused due to a misconfiguration on a specific environment, and you spent hours before you figure it out?

Or, has it never happened that certain feature of the application was behaving differently in different environments due to manual testing happening here and there, changing the state of the application in an uncontrolled way?

These are just a few examples of how bad things can go due to having too many environments.

In one of my previous jobs, we had only three different kinds of environments, and it was awesome! They were:

• The development environment — also known as the developer’s computer
• The continuous integration/delivery environment — created on-demand exclusively to execute automated tests and to run deployments, and they were automatically destroyed after that
• The production environment — the one used by our real users

What was good about having only these three environments?

We had a lot fewer problems to deal with in terms of different environments being differently configured, bugs not being reproducible in some of them, and manual testing interfering the development and delivery cycle.

I remember even arguing with our CEO that we should have a staging environment before production, to have more confidence before deploying new code that could be reaching the end users, but luckily, he made me understand and convinced me that this wasn’t a good idea.

Of course, having fewer environments cames with challenges. Below I list a few of them.

1. By having only three environments, sometimes we would introduce bugs in production because we were not able to catch them before;
2. We had to find a way to “test” minimum viable features (MVFs) with smaller sets of customers or beta testers, in production;
3. Performance testing would need to happen in production.

Actually, these are good problems to have, and they forced us to implement modern practices of software development that led us to innovation.

When you have the risk of introducing bugs in production because of the lack of environments, you’re forced to have an excellent coverage of automated tests, all of the kind. They can be unit tests for the back-end, unit tests for front-end components, integration tests between services, API tests, functional end-to-end tests, screenshot comparison tests, performance tests, and the list goes, on and on.

Also, you must have a way to roll back the application to a known, stable state, very quickly.

In a team I worked, we were able to run thousands of unit tests, hundreds of integration and API tests, close to a hundred of end-to-end tests, and a few visual regression tests in a maximum time of ten minutes. And even more importantly, we were able to roll the application back to a known good state with two clicks. The whole process would also take a max of ten minutes. This was real continuous integration and continuous delivery.

In regards to testing MVFs with customers and beta testers, this can be solved with the use of feature toggles, and proper monitoring systems. You can have all kinds of strategies when working with feature toggles if you choose the right tool to implement it. Some tools allow you to create rules like:

• Turn on this specific feature (or set of features) to 1% (or n%) of the user base
• Turn on this particular feature (or set of features) only to this user (or set of users)
• Turn on this specific feature (or set of features) only to this particular range of IPs
• Turn on this particular feature (or set of features) only to this specific region in the globe

And the list goes, on and on, with as many different combinations as you can think of.

An excellent tool that allows you to do that is the Unleash open-source feature flag & toggle system.

Of course, by using such an approach, monitoring is essential. Still, there is beauty here. When you realize that certain feature (that is behind a feature flag, and that’s turned on, let’s say, to 5% of your user base) is causing some stress to the system, and this is starting to cause problems in different parts of the app, you can toggle the feature off, and calmly investigate and fix the issue.

In terms of performance testing, there may be specific times where such tests can run in production in a controlled way, when the application is not receiving so much traffic, for example.

Of course, in some cases this might not be possible, and in such an exception, maybe it’s good to have a specific performance test environment, that is created and destroyed on-demand.

In conclusion, having less environments makes the system more resilient, and it helps you (and your company) to experiment, and really fail fast and learn and improve fast, which is essential to survive in this chaotic “environment” where new technologies are launched every day, new competitors come from all over the world, and users are more willing to change to a better experience.

That was on my mind for a while, and I’m happy that I was able to express it. I’ll be glad if you comment on your thoughts about this subject.

This content is also available in Portuguese on my WordPress blog, Talking About Testing and you can find it through the following URL: https://bit.ly/31i6JdW

My name is Walmyr, and I’m a software engineer passionate by software quality, test automation, teaching, learning, music, tattoos, and skateboarding. You can find me on Twitter as @walmyrlimaesilv, where I tweet about technology, both in English and in Portuguese.

Get to know a bit of the history behind protractor-helper and its new version

If you automate or intend to automate tests of web applications with the Protractor framework, protractor-helper will help you on making them reliable. It does that by using the ExpectedConditions class, from Protractor, to ensure that the test scripts will only interact with elements, or run assertions on them, when such elements are in the correct state, like visible, clickable, present, etc.

Automated tests of GUI (graphical user interface) are commonly seen as flaky. They fail when they should not, and so they lose credibility.

A test that fails when there’s nothing wrong with the application under test is what we call a false negative, and these should always be avoided.

Tests that are not-well-thought-through might result in false negatives. For instance, a test that doesn’t wait for a button to be on the screen before clicking on it or a test that doesn’t wait for the transition between one URL to another.

The protractor-helper library was created in the year of 2017, due to an internal need in the company where I worked at the time, to solve this specific problem, but without the complexity of the ExpectedConditions class, and since then it keeps evolving.

What are the most common functionalities of protractor-helper?

Some of the most used functions of protractor-helper are:

helper.click(element)

The above function receives an element as an argument and only clicks on it when such an element is visible on the screen and available for clicking.

helper.fillFieldWithText(element, text)

The above function receives two arguments, the first is an HTML element, such as a text input field, or a text area, and the second is a string, which will be typed into the field, only when such field is visible.

helper.waitForElementVisibility(element)

The above function, as the name suggests, waits for an element to be visible on the page. The element is passed as an argument.

Now, let’s walk through some of its latest versions.

Version 3.7.0

In the beginning, some of the protractor-helper functions, such as click and fillFieldWithText, were called clickWhenClickable and fillFieldWithTextWhenVisible. On version 3.7.0, their successors functions were created to replace them.

These new functions allowed writing shorter lines of code, which helps in code readability.

Version 3.7.8

On version 3.7.8, we announced the functions that would be deprecated because they had a replacement, but also, we decided to remove other two functions that were not in line with the primary purpose of the library, which is helping on writing robust and reliable tests.

The two other functions are the following: getBodyElementFromCurrentBrowserOrBrowserInstance and openNewBrowserInTheSamePage.

Last but not least, we also decided to deprecate the error message argument, that could be optionally passed to alter the default message in case of a failure. This decision was made due to the default messages being already very clear, suggesting exactly why a specific test step has failed. See some examples.

Version 4

Finally, we arrived at version 4, where the announced functions and arguments that would be deprecated were, in fact, removed. This is why the major version change.

Here’s what you should do if you already use a version previously from v4?

Below are listed the removed functions that have a replacement, therefore, if you use any of the functions described in the left of the below list, replace them by the relative function in the right.

clickWhenClickable - click

fillFieldWithTextWhenVisible - fillFieldWithText

fillInputFieldWithFileWhenPresent - uploadFileIntoInputField

clearFieldWhenVisible - clear

clearFieldWhenVisibleAndFillItWithText - clearAndFillItWithText

tapWhenTappable - tap

fillFieldWithTextWhenVisibleAndPressEnter - fillFieldWithTextAndPressEnter

scrollToElementWhenVisible - scrollToElement

However, if you use the functions getBodyElementFromCurrentBrowserOrBrowserInstance and/or openNewBrowserInTheSamePage, you will have to replace them by their native Protractor implementation. See the below examples.

Instead of wring:

helper.getBodyElementFromCurrentBrowserOrBrowserInstance()

Use:

browser.element(by.css('body')

And instead of writing:

helper.openNewBrowserInTheSamePage()

Use:

browser.forkNewDriverInstance(true)

Finally, if you changed the default message of some function, see the below example to understand what needs to be changed on your code.

Let’s say that the implementation of your waitForElementVisibility function is the following:

helper.waitForElementVisibility(someElement, 5000, 'Element is still visible')

Your new implementation should be the following:

helper.waitForElementVisibility(someElement)

Acknowledgment

I want to take a moment in this post to thank Paulo Gonçalves, for helping me in maintaining this library, that helps other professionals in the software industry to write robust and reliable automated tests. Thank you very much, Paulo!

And that’s it for today, but if you have any doubt, please leave a comment, and I’ll reply as soon as possible.

👋 See you next time and good testing! ✅

This post was firstly published in Portuguese, and its original version can be seen here.

In this post, I will talk about my experiences with test automation using tools that support JavaScript. In the first part of the post, I will talk about tools for test automation of the graphical user interface or GUI. In the second part of the post, I will talk about tools for integration test automation or API testing. In the third part of the post, I will talk about tools for unit testing. And in the last part, I’ll talk about tools for static code analysis.

PART 1 — AUTOMATED TESTS OF GRAPHICAL USER INTERFACE (GUI)

Selenium Webdriver

My experience with the JavaScript version of Selenium Webdriver is quite satisfactory with regards to what is possible to accomplish when using the framework, being a powerful option for GUI tests, meeting the needs of support for multiple browsers such as Chrome, Firefox, Safari, and Internet Explorer.

Other relevant points are the community support; it is an active project on GitHub and the conferences. In 2017 I had the opportunity to participate in the SeleniumConf in Berlin, and besides updating myself, I learned a lot.

Regarding documentation, until recently, it was not the best, but version 4 is coming up with excellent documentation and adhering to the specifications of the W3C WebDriver. To those interested, follows also a related content.

Another advantage of Selenium is the support for the execution of the same test case in different browsers. Great for testing chat and video conferencing applications.

Protractor

Protractor is the GUI test automation tool which I have more experience with. I’ve been working with the framework since 2014, writing content in English here on Medium and in Portuguese on WordPress, sharing videos on YouTube, lecturing at events, mentoring QA practitioners specifically on the subject, maintaining the protractor-helper library, created to help other professionals write more reliable tests using Protractor, writing two books (one in English and another one in Portuguese, both with a collection of lessons learned), keeping projects in the form of codelab and architecture suggestions on GitHub, and teaching at the Talking About Testing School, if I have not forgotten anything 😀

One of the significant advantages of Protractor, when compared to Selenium, is a simpler syntax, where you do the same things with much less code, helping with legibility and maintainability issues.

For developers used to unit testing libraries, such as Jasmine or Mocha, both are supported by the Protractor, the first being the default one.

About the documentation, my favorite part is the API, which is always updated along with the new versions.

Protractor also supports the most used browsers in the market, as well as Selenium.

TypeScript support is another of its advantages.

Finally, it is mainly maintained by the Angular team, which is supported by Google.

Cypress

Cypress is the end-to-end testing tool that I’m currently using (in some personal projects). The points that have caught my attention so far are its excellent documentation, ease of use, it enables testing of REST APIs, developer facilities such as integration with Chrome Dev Tools, debugging, interactive mode, stub support, shell command support, and automatic waits without the need of explicit delays, as well as being a very active project on GitHub.

BackstopJS

BackstopJS is the most straightforward tool I have ever used for screenshot comparison testing, also known as visual regression testing.

I have been using BackstopJS for about a year, and I am delighted. It has excellent documentation, and it’s a relatively active project on GitHub. It supports running tests inside Docker containers and supports the Puppeteer engine.

Two of my “contributions” to BackstopJS users are the backstop-config project (included in the official documentation of the tool) and the course of visual regression testing with BackstopJS (available only in Portuguese).

PART 2 — INTEGRATION TEST AUTOMATION (API TESTING)

jsdom

Jsdom is a library that can be used in combination with other tools that will be discussed here, such as SuperTest and Chai. With jsdom, it is possible to emulate a subset of a web browser to test application servers without the need for a real browser.

An example of what can be done with the jsdom library is to parse the HTML returned by a REST API call and execute something like the querySelector function to return a specific HTML element and then make an assertion that such element has a given value. Such verification may be performed using the Chai library, for example.

SuperTest

SuperTest is used to test HTTP REST calls, allowing you to test GET, POST, PUT, DELETE, and PATCH requests.

Some of the possible tests that can be done with the library are:

• Verify that the response of an HTTP request returns the correct/expected status code;
• Verify that the response of an HTTP request returns the correct location value in its header;
• Combined with tools like jsdom and chai, this can assert things like the number of HTML elements with a specific CSS selector returned after a POST request, for example.

Chai

Chai is a library of assertions for node environments but also for web browsers, so this tool makes it possible to perform checks like those mentioned in the sections on jsdom and SuperTest.

Some examples of assertions that can be performed with the Chai library when used for integration tests are:

• Verify that a particular variable, which was populated with the return of an HTTP request, contains a given string or is equal to a given string;
• Verify that a particular variable, which was populated with the return of an HTTP request, has a certain length;
• Verify that a particular variable, which was populated with the return of an HTTP request, has a specific property.

Cypress

As briefly discussed in the section on automated GUI testing with Cypress, in addition to testing interactions via the graphical user interface, it is also possible to test REST APIs.

Some examples of API testing possible to do with Cypress are:

• Verifying status codes;
• Verifying URL redirects;
• Response body verifications of HTTP requests.

PART 3 — UNIT TEST AUTOMATION

Tape

Tape is the most straightforward unit testing library I’ve ever used. Such a library already comes with its list of assertions, which makes the testing process simplified, where there is no need to import a specific library to do the assertions for the expected results.

Here’s an example project on GitHub where I used the Tape library to practice techniques like TDD, increasing code coverage, refactoring, clean code, and more.

Jasmine

The Jasmine framework enables the practice of behavior-driven development (BDD) at the unit level.

One of the significant advantages of the tool is a simplified syntax, which allows having tests that are easy to write and read.

Mocha

My impression is that the Mocha framework is the most used by JavaScript developers when talking about unit testing.

This tool enables asynchronous testing, in both node and browser environments, in a simple way.

Some of its many features include:

• Support for asynchronous tests, including promises;
• Running a single test using .only(), or skipping a single test using .skip();
• Code coverage report.

Node.js Assert

Node.js assert is a Node.js module for assertions in unit tests.

Its most significant advantage is that it is already installed together with Node.js, requiring no extra installation.

Chai

As already discussed in the section on integration testing, Chai is a library of assertions for node environments but also for web browsers.

Apart from what has already been mentioned, with the Chai library, it is possible to make assertions in the style of BDD or TDD, besides supporting the use of plugins, to extend its functionalities.

Enzyme

Enzyme is a unit testing utility launched by Airbnb to perform assertions on React components.

An example of testing that can be performed with such a tool is to superficially render a React component (shallow render) and check the number of elements with a specific CSS selector that are returned.

Here is an example project on GitHub where I used Enzyme for simple testing of React components.

Jest

Jest is a testing framework launched by Facebook, wherein the React community is primarily used for snapshot tests but can also be used for tests that require the use of test doubles, such as mocks.

Some of its advantages are:

• Because it is a complete framework, it does not require the installation of other libraries. With Jest, you write tests and assertions, execute them, and then visualize the test execution report;
• It already comes with support for code coverage reports without the need to install other specific libraries for this;
• It does not require configuration to start using it.

In the same example project on GitHub of the Enzyme testing section, I also used the Jest framework for snapshot testing.

Istanbul

Istanbul is NOT a unit testing tool but a tool for extracting code coverage metrics from unit tests.

Its primary purpose is to clearly state which parts of an application’s code are or are not exercised by tests, making it possible to identify areas of risk and potential areas for improvement.

In the same example project in the Tape section, I used Istanbul to extract code coverage metrics.

PART 4 — TOOLS FOR STATIC CODE ANALYSIS

StandardJS

StandardJS is the simplest option I know for static JavaScript code analysis, helping with code formatting and linting and making it possible to follow the same style guide throughout a project code without the need for any configuration.

ESLint

ESLint is a code linting library that enables a development team to define their style guide and ensure that such a guide is followed.

One of the features I like very much in ESLint is the auto-fix, which automatically corrects some simple rules, such as the number of spaces in tabs, single or double quotes, lack of semicolons at the end of statements, etc.

That’s it for today.

And you, which tools are you using for test automation at different application levels and for static code analysis? Leave a comment.

Did you like what you read? Help me by sharing this content on your social networks. I’ll appreciate it!

Until next time, and good tests! ✅ 👋

This blog post was originally published in Portuguese on WordPress, and it can be seen here.

A personal review of automated testing tools in the JavaScript world was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Have you already asked yourself why continuous integration is not providing value to your project or organization, even if you have all the tools and infrastructure needed for it?

Maybe the problem is in other stages of the software development life cycle, or in the process and the way the team works.

Because of this, we need to understand what’s the primary goal of this software engineering practice so that we can comprehend what to expect from it.

The purpose of continuous integration is to reduce the time between the development and the release of a working software update in production, providing quick feedback in case the new package may cause any issue to the application.

In this post, some techniques, processes and common errors that need to be avoided will be explained to help in achieving better results when doing continuous integration.

Unreliable feedback
One of the advantages of continuous integration is to have different pipelines that give us quick feedback, and that allows us to save time, besides taking the appropriate actions as soon as possible when things go wrong.

There is no benefit in having a complete continuous integration infrastructure if we can’t trust in its feedback.

For instance, let’s say a pipeline fails in the automated tests stage, but the team ignores it because it is not enough reliable to identify the reason for the failure by looking to its result. The cause may be some instability in the test environment, the data being used, or even an error in the application code.

Another example could be that there is an error in the build stage, but the team responsible for it doesn’t have the culture of fixing the errors immediately, leaving the fix for later together with lots of other issues.

The point here is that it doesn’t make any sense having quick feedback if you can’t trust in it, or if no action is immediately taken.

Slow feedback
By just using a good continuous integration tool you can not ensure that you will have quick and reliable feedback. It is also necessary to apply good practices.

Imagine working without an organized structure, without pipelines to run automated tests, without parallelism, and receiving feedback of an error only by the end of a slow regression tests suite. Is it vital to wait until the end of this process to have some feedback? The answer is no.

To make it even worse, what about if the test suite had more graphical user interface (GUI) tests than unit tests? Besides this not being recommended, it could drastically increase the test execution time and the feedback loop.

Techniques such as the test pyramid (having more unit tests than integration tests, and more integration tests than GUI tests), having a smoke test suite (to test the main functionalities first), and the use of parallelism are good examples of things that can provide us quick feedback. The point is that as soon as we find issues, as quick we can fix them, saving valuable time to any project.

Accumulation of local code pending integration
A culture that doesn’t fit with continuous integration is of a team that doesn’t integrate its code with the remote repository frequently (at least once a day). Because by integrating big chunks of code or old branches we increase the chances of having conflicts with the code in the main branch, which increases the time, complexity and cost to fix such conflicts.

One of the advantages of using continuous integration is to allow developers to refactor and integrate their code fast since every integration is analyzed by an automated build that checks if the new package won’t generate any conflict or break the code. Such automated validations can be static code analysis, unit tests, integration tests, end-to-end tests and even visual regression tests. And if the updated software is small and recent, better chances are that fixing an issue will happen quickly, in case it occurs.

With that it is encouraged that all developers in a team integrate their code at least once a day, avoiding working on long life branches.

Specific Environments
Running automated tests in shared environments where manual testing is also executed is very risky, because changes in one environment for other purposes may cause false negative results in the automated tests’ execution (e.g., a test fails because a test script was expecting some data to be available in the system, but someone deleted such data when running manual tests). This leads to the team not trusting in the feedback provided by automated tests. Another example is when tests pass with false positive results, which mean that they are passing when they should be failing. In this case, the tests are not being efficient in finding real bugs.

Is continuous integration always ideal?
Despite the many benefits of such software engineering practice, and based on what was written here so far, some minimum requirements are needed to implement continuous integration:

• Automated tests in all layers of the application
  A continuous integration tool can’t find issues on its own without automated tests that will verify if the new code has broken something.
• Usage of a version control system
  To be able to frequently integrate code a version control system is needed. This may also be the trigger for a continuous integration pipeline to start.
• The need to find and fix issues, bugs, failures as soon as possible
  There is no point in implementing continuous integration if the team doesn’t have an agile mindset to analyze and fix the problems as soon as they happen.
• Running continuous delivery and/or continuous deployment
  Continuous delivery or deployment are a consequence of efficient continuous integration, making such process automatic.
• Automatic creation of environments
  The creation of environments can also be done automatically, and in this way, it is possible to ensure that the automated tests will be executed in an exclusive environment, and no unknown factor will influence its result, making it more reliable.

Going beyond continuous integration
After correctly applying continuous integration, the next steps are to implement continuous delivery (an automated procedure manually triggered to implement a new software version in a specific environment), or even better, continuous deployment (similar to continuous delivery, but where the process is completely automated and triggered after continuous integration pipelines succeed).

These are some tips and common errors that need to be avoided to improve the efficiency of continuous integration, because besides the tools, the team needs to know and work in its concepts and practices.

This is a translation of a post created by one of my pupils (Ricardo Kohatsu). He created this post (in Portuguese) as part of a mentorship program in continuous integration between him and myself. The original post can be found through the following URL:

https://medium.com/inmetrics/erros-comuns-na-integração-cont%C3%ADnua-769556bd78d

Happy continuous integration!

When talking about test automation for web applications, we know (or at least we should know) that tests need to run in different browsers, such as Chrome, Firefox, or even on a mobile’s browser.

When talking specifically about test automation for video conference web applications, there is a bit more we need to know, such as how to simulate camera and microphone devices, since ideally our tests will be run via a CI system and a camera and mic will be unavailable.

Both Chrome and Firefox browsers provide us with the capability of having a fake media stream device and a way to disable the need for manually allowing the browser to access the camera and microphone devices, and this is what I want to show you in this blog post.

Protractor configuration for Chrome using a fake camera and mic

To simulate a fake media device on Chrome, add the following to your protractor.conf.js file:

capabilities: {"browserName": "chrome", "chromeOptions": {"args": ["--use-fake-ui-media-stream", "--use-fake-device-for-media-stream"]}}

• "--use-fake-device-for-media-stream" will make use of a fake device for the media stream to replace actual camera and microphone
• "--use-fake-ui-for-media-stream" will bypass the media stream infobar by selecting the default device for media streams

Protractor configuration for Firefox using a fake camera and mic

To simulate a fake media device on Firefox, add the following to your protractor.conf.js file:

capabilities: {"browserName": "firefox", "marionette": true, "moz:firefoxOptions": {"prefs": {"media.navigator.streams.fake": true, "media.navigator.permission.disabled": true}}}

• Marionette is the new driver that is shipped/included with Firefox. This driver has its own protocol which is not directly compatible with the Selenium/WebDriver protocol. For running tests on Firefox using the latest versions of Protractor you will need to set "marionette": true
• "media.navigator.streams.fake": true will make use of a fake device for the media stream to replace actual camera and microphone
• "media.navigator.permission.disabled": true will bypass the media stream infobar by selecting the default device for media streams

That’s it! By adding these capabilities to your Protractor configuration file you can run automated tests during continuous integration on servers without the need of a real camera and microphone.

I hope this post was helpful. Good tests!

For the command line fans, just like me, here’s a cool tip on how to run automated test scripts using Protractor before even developing them.

First, open the console of your operating system (on Mac or Linux, open the terminal, on Windows, open cmd).

If you have Protractor installed globally on your computer, run the following command:

protractor --directConnect --elementExplorer

In case Protractor is installed as a dependency of your project, execute the following command:

./node_modules/.bin/protractor --directConnect --elementExplorer

The Chrome browser should open automatically.

Then, run the following command to navigate to the official Protractor page:

browser.get("http://www.protractortest.org");

The official Protractor website should open in the newly instantiated Chrome browser.

After that, run the following command:

element.all(by.css("a")).last().click();

The tutorial page should be available.

Finally, run the following commands:

let title = element(by.css("h1"));
title.getText();

The output should be ‘Tutorial’

So, did you like it? Try what else you can do. Take a look at the Protractor API.

NOTE:

Verification commands will not work (see example below):

expect(title.isDisplayed()).toBe(true);

The above command returns the following error:

Error while evaluating command: ReferenceError: expect is not defined

The official documentation can be found here.

NOTE 2:

If you face the following issue, try using a version of Node.js not greather than 8.

WARNING: _debugger module not available on Node.js 8 *
* and higher.

I suggest using NVM to work with different Node.js versions. I have just tested with Node.js version 7.10.1, and it works fine then (tested on 21st of January, 2019).

If you liked this post, share, clap, or leave a comment!

See you on the next post, and good tests!

A bit of what happened from 9 months ago until now. By Walmyr Filho.

Time flies and I’m almost completing my first year working at appear.in, and as a person that likes to share personal learnings from time to time, here is a list of what I learned so far in this great team.

1. Automate everything you can benefit from

If you think automation is just about testing, I do not regret to inform, it is not. At appear.in we automate many different kinds of tasks, such as notifying about the status of pull requests and merges to master branch, syntax code verification, compiling and building code, deployment process, infrastructure scaling up and down, provisioning environments, and of course test automation in many different levels, such as unit, integration, UI, interoperability (more on item 6), and even visual regression testing.

The benefits of automating as much as we can are many, but one of the most important ones is that we can move fast. Even before pushing the code to the version control system, we can quickly see if our code is using the standards defined by the team, for example. By the way, this is the topic for the next item, so, let’s move on.

2. Use linting rules to “enforce” best practices

Since a big part of our source code uses JavaScript, we benefit of ESLint to define and enforce that the standards are being followed when we’re coding.

ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code. It does both traditional linting (looking for problematic patterns) and style checking (enforcement of conventions).

By using such practice, even with a team of more than 10 engineers, we ensure a coding style that everyone understands and we use good practices applied in many other successful projects. Also, this allows us to focus on what matters, instead of “manually or visually” checking code syntax.

Some examples of rules that enforce best practices are:

• array-callback-return — enforce return statements in callbacks of array methods
• camelcase — enforce camelcase naming convention
• indent — enforce consistent indentation
• and much more.

In a code review process, for instance, instead of looking to coding syntax issues, the reviewer can look at the architecture of what is being developed, and provide valuable feedback to solve such problem in a good way. And talking about code review, let’s move to the next item.

3. Code review is a very good way to improve coding skills

By practicing and enforcing the code review process we can learn with our teammate’s experience. We use git to manage versions of our source code, and this allows us to work with pull requests.

A feature branch (or a pull request) can only be merged to master after code review approval, besides having to pass all the already mentioned tests.

4. Run experiments

I’ve learned that this is one of the best ways of understanding what works and what does not work, to move or continue in a specific direction. We run A/B experiments to understand what causes a positive impact on our users, as a way to deliver to them a service they like to use. We experiment new things internally, before putting new features into production. We use feature flags so that we can deploy new features to production and experiment with a reduced group of users, allowing us to learn and improve a lot before removing the flag and making the feature available for all our user’s base. And we also experiment in “internal projects”, such as using a new technology, for example, as we’re doing with visual regression tests.

5. Learn and apply new technologies

The nice thing about technology is that it is always evolving. Every day a better way of solving specific or general problems are available and we take benefit of it. We are totally encouraged to learn and apply new technologies to make our service up to date with what is new in the market and to make sure we don’t stop in our comfort zone.

Some examples of the recent changes we did regarding of using new technologies are:

• We moved our code base from ECMAScript 5 to ECMAScript 2015.
• In some parts of our app, we are moving from AngularJS to React.
• We used to have only unit and integration tests, and now we have even visual regression tests.

6. Interoperability testing

As a video conference service based on WebRTC, we need to ensure that our service works in the browsers that support this technology, and we need to automatically test if the core functionalities of our application works as expected in real use cases, such as verifying if audio and video are being correctly sent and received when two or more people are in the same room, for example, or if screen sharing works as expected, in both free and PRO versions.

This is possible with WebRTC end-to-end tests, and we have tests for many different cases in this matter.

7. Infrastructure as code

I heard a lot about infrastructure as code before working at appear.in, but I have not had the real experience of deploying infrastructure in cloud services in an automated way and everything being code.

Many of our services run on AWS, and to create a computational instance, a security group, a network topology, a storage, or any other kind of infrastructure, we use Terraform, which makes this totally controlled and secure, to roll back to an earlier working production environment, for example, in case an infrastructure change broke something that was already working, beyond many other benefits, such as having infrastructure changes being reviewed as any other kind of code.

8. Work on small things

A very good way to make progress is by working on small tasks that are part of a big one. In our product development process, we work with 2 weeks sprints, and we move with small steps, one after the other to achieve great results.

I remember when I started working as part of this team, and instead of splitting the main task I had in smaller ones, I tried to do all at once. In other words, I worked in the same pull request for two weeks, and when it was time to merge it (after all the verifications and code review process), I needed to solve conflicts and it took at least one or two days more of work.

Today I prefer to have small achievements and work in small pull requests, even if they need to be something like part 1 and part 2, but at least this way I have a quick feedback in the code review process and I have no code conflicts to solve, or at least less (in some cases). It’s all about quick wins.

9. Refactor without mercy

It is very nice when everyone in the team understands the importance of making the code better, for being able to develop a service in a sustainable way.

In the same sprint, some of the engineers will be working on new features, others in bug fixes, and others in making the code every day better than the day before, with refactoring.

In the boy scout rule it is mentioned that you, as a boy scout, need to leave the camp cleaner than you found it, and this is what we do with our code, because we care about it, and we care about it because we know we spend more time reading code, then actually writing it. Also, because we care about each other.

We split code of big files in smaller ones for separating responsibilities and for ease maintenance. In the code review process, we suggest better functions and variables naming, for making the code readable. Also, we try to solve complex issues in simple ways, using sophisticated code standards and working with emerging architecture.

10. Pipelines as code

We use continuous integration and continuous delivery as part of our software development process, with help of a great tool called gocd, and even our pipelines are created as code, which makes the process of creating or updating a pipeline easy and low cost to maintain.

I know a lot more learnings will come and I’m looking forward to it, but I thought you would like to know a bit of what were the learnings so far, and maybe you can tell me what is your perception about all of this. Leave a comment!

If you liked the post, leave some 👏🏻, so your network will have the chance to read it as well.

Lessons learned (so far) as a software engineer working at appear.in was originally published in The Whereby Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.