Protractor within the code development process (especially testing)

Short intro: Protractor is a tool to simulate user actions on a web page allowing page testing. It is a good option for pages using angular.JS. Since recently many services are moved to web pages - it is gaining on popularity.
In bellow I'll try to introduce some topics easily for a newbie to understand and then describe my experience with the tools.

Let start with the test object. It is usually a web page with:

• front-end written in html + javascript + css
• javascript framework like angular.JS or backbone.JS or ... - if you have angular.JS then protractor is probably good for you
• front-end's back-end - usually static content mixed with semi-dynamic or dynamic content... might be simple HTML, JAVA or something similar... unfortunately might be php, perl, shell, powershell or any other crap
• backend - usually JAVA or similar running within the application server (application container or whatever you call it) - often Oracle's Weblogic (former BEA), IBM WebSphere (quite expensive and sux a bit), TomCat, JBoss or other
• database - often Oracle database or something like Apache Cassandra, MySQL or MariaDB, PostGreSQL, MongoDB, ...

And the goal for protractor lies in (the items in bold):

• Unit tests - usually written by the developers
• Integration tests - often written (partially) by the developers
• API Tests - sometimes written by the developers, often not in place and combined with integration tests
• Smoke tests - quick tests executed just to see if the development code is working someway - might be executed manually but should be (semi)automatic
• Automatic test suite - tests executed on a dedicated environment, triggered by "having new source" - usually executed automatically as a part of continuous integration
• automated code quality check (static analysis)
• code acceptance
• code building
• code deployment (onto test environment)
• automated tests execution
• tests report
• measures and metrics
• tests verdict (go or no-go)

• Nightly tests - executed from time to time (schedule based or whenever there are resources available, rarely event based) - full set of tests that runs over several hours (or even days)
• Acceptance tests (good if you are starting with good feature definition and well designed code as acceptance might be partially automated) - usually focused on the front-end only

I'll try to fill the list with more layers of the development process as the list is not complete.

Reason to move everything onto web pages is simple. Internet is accessible all the time and (almost) everywhere. It is difficult to run an app on the device only (it requires installation, platform compatibility, version checking, storage handling and many more things to handle). Your browser can handle much of that so costs can be reduced. Code is installed only on the server, it is always the latest version, platform is known (well... browsers are the new version of platforms here and their compatibility is not full).


Since the complexity of such applications is very high - we need tools to verify those. During the tests you should usually focus on a single element to verify. This applies to user interface testing as well. We have the following layers used in user interface tests:

• User interface you interact with
• This is the web page and server that it runs on
• Definition of the operations you want to perform on the interface
• This defines data to be entered
• and steps to perform
• and verification of the actions that happen afterwards
• Mocks!
• Instead of having all the layers of your application you should have a stub that emulated those layers
• You must have a clear definition of layers inter-communication
• You must focus on a single layer only (and its closest neighbors)

Web page is often tested within an actual web browser.
We simulate user actions using browser's built-in interface to do such.
Communication with this interface is usually handled by "selenium".
Selenium does what it is said by the next layer which might be, for example, the protractor with tests written in a language called jasmine.

More information to be added later :)