search

TeamMentor / TM_4_0_Design

Repo Holds TM 4.x issues
4 stars 3 forks source link

Remove dependency of upstream TeamMentor server from main 4.0 tests #367

Open DinisCruz opened 9 years ago

DinisCruz commented 9 years ago

At the moment, there is a need to have a live 3.5 server for a number of TM 4.0 test to run successfully. Not only this already a bottleneck on 4.0 tests (since it is slowing them down considerably), it is adding a dependency between these separate applications.

What we need is:

1) Refactoring of all TeamMentor 3.5 code to use only one separate module (i.e. https://github.com/TeamMentor/node-teammentor). See issue https://github.com/TeamMentor/TM_4_0_Design/issues/366 for an example of the refactoring that is needed 2) Add tests that check for current 3.5 integration/dependencies (we can re-use a lot of them). This will confirm that the 3.5 server is still behaving as we expect it to be 3) Add simple mocking (or even saved json replays) to the node-teammentor apis, so that one they execute ok, we can use them as part of the unit tests 4) ensure that we have e2e (end two end) QA tests that run on live/QA servers, covering all supported user stories (see https://github.com/TeamMentor/TM_4_0_Design/issues/246)

The power of this set-up is that we don't need to run the 2) tests all the time (when developing and when running the TM_Design or TM_Graph tests). Those tests will be executed as part of the CI workflow

romichg commented 9 years ago

This is nice but not very necessary at the moment. I question its usefulness. It is very easy to set up a local VM running TM3.5 to run all the tests locally. Moreover I am in favor of testing as a complete system as possible every time, since it is the integrations that usually fail. Anyways, moving this to sprint 4 for now as low priority

DinisCruz commented 9 years ago

Practically speaking the https://github.com/TeamMentor/TM_4_0_Design/issues/368#issuecomment-72499509 existed to avoid the problems that will occour if we need to hit the backend server for every auth test

So from a development note, this is quite important

romichg commented 9 years ago

So what is so wrong with hitting the backend with every auth test?

DinisCruz commented 9 years ago

it's slow, and the last time we did that we where DoSing the 3.5 every couple days (or hours depending on development activity)

romichg commented 9 years ago

I run a VM locally and point to this VM. Its fast and works well. It allows us to test the whole integration every time we run the tests, which makes the tests more complete.