Skip to main content

Protractor Tutorial: Jasmine test logging

Proper test logging is a crucial part of our framework setup. As long as your plan is green then everything is good, but have you ever tried to analyse test failures on CI server with no logs or test traces? Good practice is to log every important step of your tests, so that one could read our logs and understand test logic.

In previous tutorial we went through setting up new Protractor project from scratch. If you run your test, you would noticed that Jasmine’s default test output to console is rather poor. In this post we would configure more verbose and user friendly console logging from our tests.


Our goal 

If you’ve followed basic protractor project configuration, after running your tests you will see something like:


Basically what you get out of the box is dot for every it(). Well yes, not exactly the most user friendly output, not the most informative one neither. What we want to see are logs like those below:


Jasmine Spec Reporter 

Since our test runner is Jasmine, we need to add new dependency to our project:

$ npm install jasmine-spec-reporter --save-dev

After that, you should see a new entry in your package.json file pointing on latest jasmine-spec-reporter library.

Setup 

Next thing is reporter configuration. Open your protractor config file and add following lines into onPrepare function:


That’s all! Run your tests now and you should see some nice looking console output.

Further Configuration 

Jasmine Spec Reporter comes with set of configuration switches that you can apply to your setup. Whole options list with defaults:


Lets say you want to change tick icon ( ✓ ) for something else. You can use everything what’s valid for your terminal (it depends on the OS type). Since tests success is a reason to celebrate, I’ll go with beer icon:

(Mac OS X valid)

You can check my configuration below:


…and here comes our output:


Cheers!

Summary 

Jasmine Spec Reporter is simple to use and it’s an excellent way to improve our test logs. If you have any questions or want to share your own experiences, please leave a comment!

Etykiety:

Popular posts from this blog

Testing Asynchronous APIs: Awaitility tutorial

Despite the growing popularity of test automation, most of it is still likely to be done on the frontend side of application. While GUI is a single layer that puts all the pieces together, focusing your automation efforts on the backend side requires dealing with distributed calls, concurrency, handling their diversity and integration. Backend test automation is especially popular in the microservices architecture, with testing REST API’s. I’ve noticed that dealing with asynchronous events is particularly considered as challenging. In this article I want to cover basic usage of Awaitility – simple java library for testing asynchronous events. All the code examples are written in groovy and our REST client is Rest-Assured. Synchronous vs Asynchronous  In simple words, synchronous communication is when the API calls are dependent and their order matters, while asynchronous communication is when the API calls are independent. Quoting Apigee definition: Synchronous  If a
Read more

Rerun Flaky Tests – Spock Retry

One question I get asked a lot is how you can automatically rerun your test on failure. This is a typical case for heavy, functional test scenarios, which are often flaky. While test flakiness and its management is crucial and extensive matter itself, in this post I want to give a shout to the extremely simple yet useful library: Spock-Retry. It introduce possibility to create retry policies for Spock tests, without any additional custom-rules implementation – just one annotation. If you are not a fan of Spock testing framework and you prefer JUnit – stay tuned! I will post analogous bit about rerunning JUnit tests soon. Instalation  If you are an maven user, add following dependency: <dependency>       < groupId > com.anotherchrisberry < /groupId >       < artifactId > spock-retry < /artifactId >       < version > 0.6.2 < /version >       < type > pom < /type >   </dependency> For gradle users:
Read more

Performance Testing – Vegeta Attack!

Performance testing is crucial field of modern software development. Taking into account that in today’s world majority of app’s communication is web-based, it turns out to be even more important. However, it still enjoys less interest than automated functional testing, and publications on load testing subject usually focus on mature and complex tools like JMeter or Gatling. In this post I’d like to introduce command line usage of a super simple and lightweight tool for performance testing of HTTP services, which is Vegeta. Who is Vegeta  Besides Dragon Ball’s character, Vegeta is a simple load testing tool written in GO, that can be used both from command line and as an external library in your project. In order to use Vegeta, download executables from here . It is recommended to set environment variable for ease of use.  For Mac users, you can download vegeta directly from Homebrew repositories: $ brew update && brew install vegeta Vegeta’s Arsenal  Usage
Read more