Regression testing

Hi Francesca Shiekh,

First of all, I feel for you!  It is definitely complex and time consuming to write all test cases, and even more after the fact. Definitely life savers for long multiple phases projects though.

If I were you, I would probably start by prioritising the functionality that is most complex (and therefore most likely to break with any additional change to it) to the one that is least complex.

Then I would move on to the integration testing first by testing the API interactions (assuming for a second that we are only on a sidecar only world right now), where you basically test all API's that have a special behaviour (custom APIs, logic hooks etc).

Once that's done, at least you know that the final results of interactions between clients and server, for specific use cases have some test coverage.

Then I would move on the UI part of that, where you automatically test custom ui behaviour that results in the integration testing.

Once those two are done, you sort of have full proactive coverage of what could go terribly wrong in a system at a broader level.

Finally I would move to server side unit tests and then client side unit tests. As far as I understand, it can be really complex to embed unit tests after the fact, as it might require quite a bit of refactoring.

In parallel to all that, I would try to bake into the development process (wherever practical) all the above steps for the newly built custom functionality.

In regards to tools, I would encourage you to have a look at Sugar's public (and semi private that you might have access to) git repos and pick and choose the best for you.

I hope this gives you some hints to start this journey, and please do share your lessons learned as you go!

Thanks!

Hi Francesca Shiekh,

First of all, I feel for you!  It is definitely complex and time consuming to write all test cases, and even more after the fact. Definitely life savers for long multiple phases projects though.

If I were you, I would probably start by prioritising the functionality that is most complex (and therefore most likely to break with any additional change to it) to the one that is least complex.

Then I would move on to the integration testing first by testing the API interactions (assuming for a second that we are only on a sidecar only world right now), where you basically test all API's that have a special behaviour (custom APIs, logic hooks etc).

Once that's done, at least you know that the final results of interactions between clients and server, for specific use cases have some test coverage.

Then I would move on the UI part of that, where you automatically test custom ui behaviour that results in the integration testing.

Once those two are done, you sort of have full proactive coverage of what could go terribly wrong in a system at a broader level.

Finally I would move to server side unit tests and then client side unit tests. As far as I understand, it can be really complex to embed unit tests after the fact, as it might require quite a bit of refactoring.

In parallel to all that, I would try to bake into the development process (wherever practical) all the above steps for the newly built custom functionality.

In regards to tools, I would encourage you to have a look at Sugar's public (and semi private that you might have access to) git repos and pick and choose the best for you.

I hope this gives you some hints to start this journey, and please do share your lessons learned as you go!

Thanks!

Francesca Shiekh,

I just finished building a docker container ( https://github.com/esimonetti/ThornDockerized ) to simplify the use of SugarCRM's REST API testing utilities called Thorn (https://github.com/sugarcrm/thorn ).

That integrates together few things: a working environment with all its dependencies, the actual Thorn library and its dependencies and a sample API test to get you started.

Let me know how this goes!