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.


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:



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!

Popular posts from this blog

Notes after TestingCup 2018

On May 28-29th I attended TestingCup conference in Łódź. Having quite unique perspective: this was my second year in row as a Speaker at this conference I want to share some thoughts on the event. Dust has settled, lets go! 

Championship Originally TestingCup is a software testing championship. Wait, what? Yes, the formula is unique: teams and individuals from all around Poland are competing in finding the most bugs and defects in specially prepared application - Mr. Buggy. I don’t have specific data, but since this year’s conference was all english I guess competitors were not only from Poland. As a spectator, I must say that the whole competition looked very professional. There were team shirts and names, podium and trophies (gold cup and cash). 
Some cons? Testing championship is held at the first day of the conference. So this is already a conference, but if you’re not taking part in the championship… there’s not much to do, since all the talks are in the next day. Organizers are aw…

REST-Assured framework overview

In modern software development, REST services becomes most popular choice for implementing distributed and scalable web application. They are light and easy to maintain, which results in faster and more effective implementation and system integration.
I recommend you also my other posts about REST-Assured and building microservice’s test automation frameworks: REST-Assured: going deeperBuilding microservices testing framework
With the increase popularity of RESTful services, there is a need for fast and lightweight tool for REST webservices testing automation. One of the most popular choice is Rest-Assured framework from Jayway. It introduces simplicity of testing web services from dynamic languages like groovy or ruby to java. In this post we will get our hands dirty and write automatic test in Rest-Assured framework.
In order to create complete implementation of automated tests in Rest-Assured framework, we need to write our code against some example API. We’ll use standalone Wiremock m…

Building microservices testing framework

RESTful services and microservice architecture in general are big trends in the industry right now. I’ve noticed it also from this blog’s traffic analytics, where topics related with REST testing get the highest interest. Therefore I’ve decided to create some kind of example framework for RESTful APIs functional testing. Project is based on REST-Assured as a services client, Spock as a testing framework, Groovy and Gradle. You can clone full repository from my github. Tests are run against Wiremock API described in this post. Please consider this project as a kind of bootstrap, since it’s an example, not full-blown test framework. Ok, so as Linus said – talk is cheap, show me the code!
Dependencies Usually, first thing for me after importing new project is opening build.gradle (or pom.xml, in case of maven). In our example, the most important dependencies are REST-Assured and Spock. We’ve also Jackson, for serializing objects, Logback for our logs and snakeyaml for reading .yaml files,…