Good Bye Blog !!

I have migrated my Blog to a new address http://pankajmalhotra.com Readers stay tuned there's a lot more to come ahead !!

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.

We need it !! Oh wait... do we ??

Ok after stumbling upon various IRC channels, having talk to some top most QA testers, Automation geeks, and  API developers this week I am here with a few thoughts. So this week was a part of my research period, My main goals for this week were :

Goals for this week

First Task

This week I will mainly concentrate on exploring and researching about the model of the testing that we are going to use for this application. Whether a change is required or not ? If yes are we in a position to make that change ? If no , explore more about other methods that can tackle the problem for database object modelling.

• Explore more about the number of tests that require modelling of database objects to make sure that do we really need FactoryBoy and how will it be useful.
• If we need FactoryBoy then can we merge the code for tests with the application code ? Explore advantages and disadvantages for merging the code.
• If we cannot merge the code are there any other alternatives that will allow better modelling of Database objects ?

  

After answering these questions with concrete arguments and proofs I would like to discuss it with the team and may be have a poll ?

Some of the references I am exploring:

http://sqa.stackexchange.com/questions/2143/keeping-automation-code-away-from-application-source-code/

http://sqa.stackexchange.com/questions/1260/whats-the-recommended-practice-for-separating-unit-tests-from-integration-tests

https://groups.google.com/forum/#!topic/selenium-users/2KH8v7vVBs4

I will also like to explore the problems and limitations(if any) that might arise if we are ready to use FactoryBoy using past examples from Rails applications testing using FactoryGirl and see if we have a solution to them.

Second Task

The second task I will like to take up this week is to discuss with lizzard, pragmatic, rbillings, marcia and team to come up with a more specific design for template for task creation as discussed in meeting yesterday.

The template would later help to autofill the tasks after scraping bugs data from other API’s,

inturn helping in Task creation automation that I proposed in my proposal.

Along with this I will use this time to become familiar with OneandDone codebase.

So I have roughly achieved most of the tasks on the list, and have explored many resources related to Test Automation.

Here are some resources that I went through and found really very useful

1 Talk on testing django applications using pytest by Andreas Pelme(who himself is an author of pytest-django) Link to Video
2 Talk on Integration and Functional Testing using LiveServerTestCase and Selenium Link to Video
3 A Presentation on Testing and Django Link to Slides

I also came across some of talks from very experienced Python developers who highlighted the advantages of pytest for easier and better testing.

1 Holger Krekel: Improving automated testing with py.test Link to Video

2 Andy Todd: Why I use py.test and maybe you should too  Link to Video

Also while talking to a one of the pytest developers I came across a completely new framework for automated testing : Robot Framework

I believe this is as far the most advance tool for acceptance testing that I came across which integrates with Selenium to provide better test coverage and test outputs as shown in one of videos Link to Video

But our existing test suites are quite different from the Robot Framework and we are more concerned about Integration + Functional testing. So in our case it might not be of much use, but really it was a fun to get to know more about this framework.

Exploring these tools and talking to so many developers, I am in an opinion to keep the test suite with application itself so that we can use FactoryBoy for better data population along with pytest fixtures but since this time the tests will be with the application itself we have an option for using LiveServerTestCase  or the original pytest-mozwebqa plugin. 

I am still not sure about how pytest-mozwebqa will integrate with Fixtures and LiveServerTestCase if we use it, but I am looking forward to talk with my mentor and team about it and finalize the tools by next week.

Google Summer of Code with Mozilla !!!

This a Big Moment and I am extremely happy to say that I have been selected by Mozilla as a Google Summer of Code Student  :D :D

My project is to add :
Functional Test Suite and Features for QA Taskboard - One and Done 
Detailed Proposal for the project is here

I would be working with the Web QA team and under the awesome mentorship of Bob Silverberg (:bsilverberg). I will be blogging about my weekly progress here, So keep an eye if you are interested.

I would like to express special thanks to Stephen Donner, and Bob Silverberg who always stood up for help whenever I asked them and to the whole Web QA team. I still remember the first time when I joined you all on IRC looking for Dave Hunt to put in my first patch and was welcomed warmly by Zac Campbell.

O am I forgetting someone ? YES , I forgot the one who always gives me badges !!! Yes I am talking about Rebecca Billings :D Florin, Andrei, Raymond, Matt, Krupa : You all are really awesome. Once again thanks team, its a pleasure to work with you all and would always be, I would try my best to complete this project on time and never let you down.

This Summer is gonna be great, Thanks Mozilla !!!

Factory Boy !

This Post we are gonna talk about FactoryBoy, Although the original documentation on FactoryBoy website is very good, short and precise , but still here are some quick notes which would get you started and for any Reference would be much useful.

So What is FactoryBoy ?

FactoryBoy provides a default way of getting new Instances,while still being able to override some fields on per-call basis.

Advantages ?

1. Particularly useful in handling situations which require creation of object, interacting with database, it provides safe/better way for data population and instance creation.
2. Provides support for multiple build strategies (saved/unsaved, attribute dicts, stubbed objects)
3. Powerful helpers (sequence, sub-factories, reverse dependencies), which we are going to talk about later in this post.

Let's start with an example:

We have a model object Poll which has

• A polling question
• Date on which Poll is published
• A function to check if the poll was published recently

To tests such kind of an object we can create tests like

• Create a poll with future publishing date and check if it was published recently
• Create a poll with past publishing date and check if it was published recently
• Create a poll with recent publishing date and check if it was published recently

This test could be easily modified to use factories like:

Define factory classes to make instances in factories.py like:

As in above example factories declare a set of attributes used to instantiate an object, whose class is defined

in FACTORY_FOR attribute.

A given class might be associated to many factory subclasses by having different default values for attributes in Factory class example

A User class might be related to Userfactory(), FemaleUserFactory(), MaleUserFactory()

each having different value for the gender attribute.

Now after creating a factory we can modify our tests to use the factory class to instantiate a new object like

As is visible it is possible to override the default values for attributes in factory class by passing new values for these attributes example

Value for pub_date is passed in this case to create a post with past date.

Some of the helper functions come handy with factory class are:

Sequence declaration:

When a field has a unique key its value must be different, thus these unique values can generated like

username = factory.Sequence(lambda n: 'user%d' % n)

Lazy Attribute:

For fields deduced from other fields like

username = factory.Sequence(lambda n: 'user%d' % n)

email = factory.LazyAttribute(lambda obj: '%s@example.com' % obj.username)

Here email is deduced from username

Inheritance:

Same as normal inheritance, we can override attributes for parent class

Non-kwarg arguments:

Some classes take a few, non-kwarg arguments first.

Strategies:

Factories support two built-in strategies

MyFactory.create() provide a local object and saves it to database

MyFactory.build() provide a local object

Database dependency issues:

Dependent objects(Foreign keys):

first_name = factory.Sequence(lambda n: "Agent %03d" % n)

group = factory.SubFactory(GroupFactory)

Here the group attribute is a foreign key for user table and thus it becomes a SubFactory in factory class.

Other such issues like

Reverse Dependencies(Reverse Foreign Keys)

When a related object should be created upon object creation

Simple ManytoMany

Building the adequate link between two models depends heavily on the use case

ManytoMany with a 'through'

do exists. Examples for which can be found here

Fuzzy Attributes:

These are used to create random data for various datatypes and also while creating this data we can specify some limits so that we can generate it according to our needs. example

fi = FuzzyInteger(0, 42)

fdt = FuzzyDateTime(datetime.datetime(2008, 1, 1, tzinfo=UTC))

Thus this is a very quick introduction to FactoryBoy, which makes it clear what is it used for and how to use it.

There are many other attributes, functions, and strategies which are discussed in detailed documentation with some very good examples to get a deep insight.

TREAP ( Binary Search Tree + Heap )

Getting back to Data Structures after quite a long time :P ( Hope this makes a good read )

Useful links to understand TREAP :
http://faculty.cs.niu.edu/~freedman/340/340notes/340treap.htm
http://www.cs.cornell.edu/Courses/cs312/2003sp/lectures/lec26.html
http://electures.informatik.uni-freiburg.de/portal/download/7/8207/04_Treaps_4up.pdf
http://ieng6.ucsd.edu/~cs100s/Exams/TreapExamples.pdf

Input :
i n      // to insert n
d n    // to delete n
s n    // to search for n
p      // to print the current situation of treap

HEAP (Min Heap)

Ok its been a long time i have posted here , but the Data Structure i am

gonna discuss today is one of the most frequently used Data Structure . Its called a HEAP or a priority queue . Its a DS in which the data is stored
depending on the priority set by the user.

 So the fact i am gonna use here is that
the element at the root  should be less than both of its left and right child
and the binary should be a complete binary tree.

                            
So to implement such kind of a DS we actually do not need to implement the binary tree , we can make a wise use of array as :

                             

Inserting an element:

• In the Shuffleup operation, the value of a position,is compared with that the value of its parent.
• If the value is smaller than its parent, then they are swapped.  
• This is done until either value is bigger than the value at its parent or we have reached the root.

 Deleting an Element:

• This is done by first relocating it to the root,satisfying the complete binary tree property.
• This relocation may however violate the heap invariant.
• To restore the heap invariant, we perform what is known as Shuffle-Down.

Shuffle Down:

• In Shuffle-Down, analogous to Shuffle-Up, we move the element down the tree until its value is at most the value of any of its children.
• Every time the value at a node X is bigger than the value of either of its children, the smallest child and X are swapped. 

Explanation for the Code:
I x ( insert integer x in heap )
D ( Delete the minimum element from heap )
P ( Print the heap )