From a PIE to an API !!

Last week we were pretty much concerned about what to use and what not ?
and what changes we shall introduce in our model of Testing ?

So may be if you have curiosity about what we used and what we decided, This post is for you !

Overall Scenario last week: We wanted to use FactoryBoy for database object modelling and reliable data for tests.
So using FactoryBoy meant that we had to keep our Functional Tests with the application itself.
This was the change we decided to have and pretty much kicked of the work and initialized the test objects in application repository.

So what next ?
In our old testing model we ran the Functional tests on staging/production application already running. So now the challenge was:
How will we trigger the server ?

One of the solution which instantly came to mind was using LiveServerTestCase 
So things were *almost* finalized !!

But things come to mind as we start working, and this time it was not something which could be ignored.
Man, we would not be able to run the tests on Staging and Production or in general any other remotely hosted clone of OneAndDone, Also running the tests locally would mean setting up of a local instance of OneAndDone. This was what came to mind as soon as I began writing the first test and it was for sure not what we wanted, because  of mainly two reasons:

1. Why will a contributor developing a test case want to set up the application locally ? We definitely don't want to assume our contributors to be Application developers. So this was a hindrance for contributors.
2. We wanted to run the tests on staging and production because it gives us a better idea of current state of Application.

So we decided to give it a rethought.

After many discussions with other team members it settled down to two options:

1. Keep the tests local for better data population and faster test runs.
2. Have the tests in a separate repository making it easy for contributors to work on and to make us able to run the tests on stage/prod.

Finally we decided to go with the second one because of the above mentioned limitations of first, or the benefits of second overpowered the benefits of first. We realized our current model to be more advance than most of the other methods discovered.

The main changes we decided to have in these tests that make them better and advance than the tests for most of the other Web QA projects are:

• Develop and Use a REST API which interacts with database objects remotely. So it helps us to create/delete the test data. For developing this API we decided to use Django REST framework over tastypie for some reasons based on prior experiences of developers.
• We decided to use pytest fixtures instead of SetUp and TearDown methods which will allow creation/deletion of mock objects using the REST API.

We again kicked off the work by initializing the Page Objects and Base Class and opened some Test Case bugs.
Now I am looking forward to developing the REST API and start writing the tests next week.