Sprint 121 task for naverma

[naina-verma]

1. Where to place the test scripts? Which git repo?
2. When the tests should run? Where to add the steps?
3. Build for the test code? (Protractor - npm build)
4. Who should receive the notification? Which email account will be used to the mail from? Is there service account available? Could be part of the Jenkins.
5. Acceptance criteria: login - create work item - logout
6. Covering Deployment acceptance criteria should be testable fabric8-services/fabric8-wit#180

[ldimaggi]

Notes on the tests:

Test repo - Where do we want to store the tests? Would we want to to maintain the tests in this repo:
https://github.com/almighty/almighty-spec ?

The first thing we have to work on for these tests is indeed the way we build or find the environment to test on. The most common thing would be to start the entire system locally and then execute the tests. Naina is looking at using Ansible for the test setup - this night be the easiest approach to follow as we have to consider all teh npm-related packages that we have to install.

And - we have to think about the multiple repo;'s that we have to download and build - alm-core and alm-ui - are others needed?

Thx!

[michaelkleinhenz]

We'll need a database with a starting point schema.
I would skip the source step and just test the containers from the registry. These are the binaries that get deployed after all.
I'd use Ansible and some simple build management like Grunt to do the following steps:

1. Use Ansible to pull and start the database.
2. Create the initial database schema and some predefined test data in it.
3. Create configuration files and other needed volume contents for the application containers.
4. Use Ansible to pull and start the application containers (UI, Core) with meaningful settings.
5. Pull the test specs using git from the UI project.
6. Run the test specs on the running containers using Jasmine and some test runner.
7. Run possible additional non-UI-project specs on the containers.
8. Tear down the system.

A single step in here is not that complicated, but the complete thing will be a bit complex. I'll strongly recommend Grunt or some other tool that allows basic runtime control over all steps.

[michaelkleinhenz]

@ldimaggi I think the -spec repo is for the WI/WIT specifications. I'd create a new repo almighty-e2e or something. And in the long run, I would expect that the Jasmine specs for the functional tests are in the -e2e repo, not in the UI repo. The UI build would have to pull them from the -e2e repo on test.

[aslakknutsen]

@michaelkleinhenz It is not. It's intended to be a general user story spec repo.

[ldimaggi]

For the test setup - can we re-use what is currently in use for the production server?

[kbsingh]

@ldimaggi @michaelkleinhenz and I had a short call around this topic, and how we might setup to use the existing openshift infra. We've talked through a broad plan like this :

[joshuawilson]

@ldimaggi @kbsingh @michaelkleinhenz are there actual tasks that can be assigned out of this issue? Or is it just a discussion?

@naina-verma have your original questions been answered?

[kbsingh]

@joshuawilson todays call was really to : 1) talk through the option of using the existing openshift infra to run these e2e tests, answer was : Yes, and then 2) to try and brainstorm quickly a process we might use. the Map above talks through the scope and potential process

[joshuawilson]

@naina-verma @michaelkleinhenz Can we close this?

[ldimaggi]

I'd like ti keep this open for a couple of more days - we can use a 48-hour deadline to get us to complete the definition of the configuration that we will want to use for the set-up of the automated end-to-End tests that we will build - especially in the context of the mocking layer that Michael has proposed for the UI tests.

[ldimaggi]

If no one objects, I'm going to close this issue - and open up a new issue that will focus on the task of our creating the full stack/core test environment that we will require for EE/system tests. Thx!