Your First Protractor Test in Visual Studio 2015

Introduction

In this article we'll see how we can create our first project in Visual Studio 2015 that uses Protractor to test an angularJS application.
What is Protractor: "... is an end-to-end test framework for AngularJS applications. Protractor runs tests against your application running in a real browser, interacting with it as a user would."
The official site is this: http://angular.github.io/protractor/#/. 

Why to use Protractor

The main reason for using Protractor is that will recognize specific AngularJS identifiers, like model, repeater, etc.

Another important reason for using it is that when running tests you don't need to wait until the response will return.

Requirements

In order to be able to run Protractor tests we need first to have
- java sdk installed: http://www.oracle.com/technetwork/java/javase/downloads/index.html
- node.js installed: https://nodejs.org/en/download/
- NodeJS Tools for Visual Studio 2015: https://www.visualstudio.com/en-us/features/node-js-vs.aspx

Installation

After node.js was installed on your computer you can use npm to install Protractor globally with:

This will install 2 commands, protractor and webdriver-manager. To verify if protractor was installed run this command in your cmd: protractor --version. Protractor is installed globally under: c:\Users\yourUser\AppData\Roaming\npm\. Webdriver-manager is the tool that will instanciate a Selenium Server. In order ro use it and to start it we need to:

This needs to remain opened while you are running your tests. It will start up the Selenium Server and will output logs. Protractor tests will send requests to this server to control a local browser. 
Below you can see in mode details what Protractor's doing:

Writing your first test

Open Visual Studio 2015 and create a new project of type Blank Node.js Console Application. 

Delete app.js, because you'll don't need it. You'll notice that in your npm references, protractor will be available as a global one.

Protractor needs 2 files to run, a spec.js file that contains the tests and a conf.js file that will tell what specifications will be run and where to talk to Selenium Server (seleniumAddress).

Add the conf.js and spec.js files to your project.

Spec.js should have the structure below, where describe and it represents Jasmine framework syntax. Browser is used by Protractor to navigate in the browser.

If webdriver-manager is already started, now you can run your test in the command line where your conf.js file is by using this command:

A Chrome browser window will be opened. In your cmd you should see the test result.

Using IntelliSense

If you want your jasmine, protractor syntax to be recognized in Visual Studio you need to do additional steps:
- open a cmd and run these commands npm tsd -g 
- then go to the location of your project (in our case c:\temp\Protractor\MyFirstProtractorExample\MyFirstProtractorExample\) and run the following commands 
tds install jasmine
tsd install angular-protractor
tsd install selenium-webdriver
These commands will install the necessary typings for your project

- then you need to add the typing reference to your spec file

More about AngularJS Testing you can find in this book: AngularJS Test-driven Development

Happy testing and... make it green, becomes a dream :).

SpecFlow - Using Hooks in your Tests

Introduction

In a previous article we talked about how we can create tests with Selenium and SpecFlow.This article explains how we can use Hooks to run our tests.

What are Hooks

Hooks = event bindings and can be used to perform additional automation logic on specific events, like, for example, the execution of a scenario. To make an analogy, think about Setup and Teardown attributes from nunit framework.

Types of Hooks

The names are intuitive

- Beforetestrun and aftertestrun represents the code that will be executed before and after all tests

- Beforefeature and afterfeature represents the code that will be executed before and after every feature

- Beforescenario and afterscenarion represents the code that will be executed before and after every scenario inside a feature

- Beforescenarioblock and afterscnearioblock represents the code that will be executed before and after every scenario block

To be more precise, below you can see an example of a scenario with 3 blocks. The test will be executed before and after Given/When/Then blocks

- Beforescenariostep and afterscneariostep represents the code that will be executed before and after every scenario step

Creating Hooks File

After you added the Spec Flow extension to your visual studio project, you are able to create a new item of type Hooks.

A default class is created:

Modify this class and add all hooks you need.

Restrict Hook Execution with Tag Filtering

Another specflow feature is to restrict hook execution based on the tags you set to your scenarios. If you didn't know for a scenario you can add a tab. Based on this you group your tests when running them. In the image below, the scenario tags are @Login and @forgotPassword

The code below from you hook file will be executed for those scenarios tagged with @Login and @forgotPassword (when we are in if)

Want to lean more about BDD? Have a look on this book: BDD in Action: Behavior-driven development for the whole software lifecycle

Happy testing and... make it green, becomes a dream :).

Clone your VSO git Repository locally

Introduction

This article explains several ways to clone your git project locally.

From Visual Studio

To get starting you need to clone the repository to your local machine. To find the repository login with your Microsoft account, Click on Clone and observe Clone URL. That’s what you are looking for:

Open Visual Studio 2013 or 2015, connect to your project and click on Clone this repository. Enter the local path where you want to store the project and press Clone button.

To add new files/presentations/code, in the cloned repository add them and then go to Team Explorer à changes. Enter a comment and click Commit and push. If you have untracked files add them to the project.

You can find more documentation about this topic on: https://msdn.microsoft.com/en-us/library/vs/alm/code/git/get-started

From Windows PowerShell

Open Windows Powershell. Go to the location where you want to clone your project. Type command:

Git clone repository_url:

Add your new file with command git add filename. Commit your file with git commit file name. Add to repository with your file with git push. To take files added by others perform a git pull. More documentation about this:

https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository

From GIT for Windows GUI

1.       To do this install it from: https://git-scm.com/download/win

Open GIT GUI:

More about GIT version control you can find in this book: Version Control with Git: Powerful tools and techniques for collaborative software development.

Happy testing and... make it green, becomes a dream :).

Build Triggers in Jenkins

Introduction

This article explains how you can trigger your builds in Jenkins.

Build Triggers

Open any build configuration and search for Build Triggers group.

Check Build periodically. In this filed you can enter values in this format: * * * * * where

1* MINUTES Minutes in one hour (0-59)
2* HOURS Hours in one day (0-23)
3* DAYMONTH Day in a month (1-31)
4* MONTH Month in a year (1-12)
5* DAYWEEK Day of the week (0-7) where 0 and 7 are Sunday

Examples:
0 8 * * * will trigger the build every day at 8 AM
0 8 * * 7 will trigger the build every Sunday at 8 AM

More about Jenkins Essentials you can find in this book: Jenkins Essentials

Enjoy the book!

Happy testing and... make it green, becomes a dream :).

Deleting your Test Plans from TFS

Introduction

This article explains how you can delete your test plans from versions >= TFS 2012 via Developer Command Prompt with witadmin.

Why like this?

Trying to delete the test plan from MTM or from TFS web UI is not possible.

So, In MTM2012/MTM2013/MTM2015, there is no direct way to delete a test plan. We need delete the corresponding work item using TFS command line options in command prompt in order to delete a test plan.

Developer Command Prompt

If you installed Visual Studio 2012/2013/2015 but you are not able to find the “developer command prompt” in your Windows 8/10 environment, the solution is simple. Go to folder: “C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\Shortcuts” (12.0 varies depending on the VS version).

Run witadmin command

Then, you need to run your command for deleting the test plan:

witadmin destroywi /collection:http://<your server name>:8080/tfs/<your collection name> /id:<the id o the test plan you want to delete>

More about TFS 2013 you can find in this book: 
Professional Team Foundation Server 2013 (Wrox Programmer to Programmer)

Enjoy the book!

Happy testing and... make it green, becomes a dream :).

Agile Testing

A few days ago I started to read a book about testing: Agile Testing: A Practical Guide for Testers and Agile Teams.
The book is in the top 10, best books about testing, it is written by Lisa Crispin and Janet Gregory, testers with extensive experience in both traditional as well as agile projects, in large or small teams.

Below is an excerpt from the book that you might find interesting:

"WHAT DO WE MEAN BY AGILE TESTING?

You might have noticed that we use the term “tester” to describe a person whose main activities revolve around testing and quality assurance. You’ll also see that we often use the word “programmer” to describe a person whose main activities revolve around writing production code. We don’t intend that these terms sound narrow or insignificant. Programmers do more than turn
a specification into a program. We don’t call them “developers,” because everyone involved in delivering software is a developer. Testers do more than perform “testing tasks.” Each agile team member is focused on delivering a high-quality product that provides business value. Agile testers work to ensure that their team delivers the quality their customers need. We use the terms “programmer” and “tester” for convenience."

"WHOLE-TEAM APPROACH

One of the biggest differences in agile development versus traditional development is the agile “whole-team” approach. With agile, it’s not only the testers or a quality assurance team who feel responsible for quality. We don’t think of “departments,” we just think of the skills and resources we need to deliver the best possible product. The focus of agile development is producing highquality
software in a time frame that maximizes its value to the business. This is the job of the whole team, not just testers or designated quality assurance professionals. Everyone on an agile team gets “test-infected.” Tests, from the unit level on up, drive the coding, help the team learn how the application
should work, and let us know when we’re “done” with a task or story. An agile team must possess all the skills needed to produce quality code that delivers the features required by the organization. While this might mean including specialists on the team, such as expert testers, it doesn’t limit particular tasks to particular team members. Any task might be completed by any team member, or a pair of team members. This means that the team takes responsibility for all kinds of testing tasks, such as automating tests and manual exploratory testing. It also means that the whole team thinks constantly about designing code for testability. The whole-team approach involves constant collaboration. Testers collaborate with programmers, the customer team, and other team specialists—and not just for testing tasks, but other tasks related to testing, such as building infrastructure and designing for testability.
The whole-team approach means everyone takes responsibility for testing tasks. It means team members have a range of skill sets and experience to employ in attacking challenges such as designing for testability by turning examples into tests and into code to make those tests pass. These diverse viewpoints can only mean better tests and test coverage.
Most importantly, on an agile team, anyone can ask for and receive help. The team commits to providing the highest possible business value as a team, and the team does whatever is needed to deliver it. Some folks who are new to agile perceive it as all about speed. The fact is, it’s all about quality—and if it’s not, we question whether it’s really an “agile” team. Your situation is unique. That’s why you need to be aware of the potential testing obstacles your team might face and how you can apply agile values and principles to overcome them."

Enjoy the book!

Happy testing and... make it green, becomes a dream :).

Bug Magnet - A 'nice to have' Chrome extension

Introduction

Bug Magnet it's an useful extension for testers that gives you the possibility of entering values for inputs in a web page and that can be helpful in your exploratory testing, via a right-click context menu.

 

How to Use it?

Very easily. Add your Bug Magnet to Chrome. Right click any input in your application and open Bug Magnet contextual menu. This will add common problematic values and edge cases to the context menu (right-click) for editable elements, so you can keep them handy and access them easily during exploratory testing sessions. Examples:
- valid/invalid emails

- sql injection

- html parsing

- numbers, etc

Happy testing and... make it green, becomes a dream :).