Tuesday, August 14, 2012

Life in WSO2

I had lot of technical articles so I thought having two photo articles back to back will not be a problem. Going through Lasindu's (if you read my previous article you might know him by now) fb profile I saw another nice album on WSO2 internship. Now this is the photographer. Thanks dude for letting me publish them on my blog :D

Btw, I did get the permission to publish this photo. :P






Lets take a look at this album!! I think this is a tea time in WSO2.


 Talking about this photo, 4 of them are really good at playing TT :P. And below is a training time!!




WSO2 7th Anniversary Celebrations

We celebrated our 7th anniversary few days back. We had to go to the 59 to join the party. Below are some memories from that. These are captured by one of our interns, Lasindu Charith. I can call him the official photographer in WSO2, at least among interns :P

It was a little party:) But there was enough food too :D


And one lucky guy got to celebrate his birthday on the same day!!
 

Things that you should remember when test automating(best practices)


Less Hard-coding
We are always tempted to hardcode things. It make our life easy. But this can make maintaining that code a big issue. I had to change some of the places that I did hardcode due to different reasons.

Dates and times
When working with date and times you might forget that, those things are changing. I did this mistake ones in the testing. I was asked to test the service locking functionality. We can lock a service for a specific time. I just hard-corded the dates and times and did the testing. Soon I realized that, if we are going to use them in the future, test going to fail. You might think that is foolish from me, but believe me we miss those little things while cording.

Use of Constants
If you really need to hardcode something do it through a constant, at the bigging of the code. So if it get changed, it is easy for someone else to find and change it

Do not leave thing behind
When you create any objects for testing and if you have done any configuration changes to the product for testing, make sure you undone them before you leave. Those objects and changes can break other tests by other users. You can use @AfterClass for that purpose.

Avoid Test anti-patterns
Just search for the test anti-patterns and you will find lot of them that you should avoid, or at least try to avoid.

Coverage Vs Stable Product
When we are testing, we normally get blinded by the coverage. But always our goal should be to build a stable product. No matter what is the test coverage if our product is failing, all the hard work is for nothing. This is told to me by our team lead Krishantha ayya.

Good Articles

Clarity Framework


Based on the training session and the slide-set provided by Dharshana, and Krishantha.

Clarity is a easy and optimized way to do the integration testing. It can automate platform-wide scenarios , execute tests against stratos and private clouds, adopt tooling(Selenium , SoapUI , Jmeter , Ravana, WSO2 Ravana is an opensource benchmark test framework that aims to facilitate performance benchmarks of different servers. ) support to automation , do reporting and keeping historical records.

Architecture

Work similar to TestNG.


  • This is the component level view of the architecture.



More information:

Monday, August 13, 2012

Beginning the Test Automation



We got this order to freeze our current project and join the test automation project, which was lead by Krishantha Samaraweera. 23 of us were divided in to 2 groups and assigned two of our major products, ESB and GREG. I am in the GREG test automation team. Here we are using a test framework called as 'Clarity'. Clarity was wso2 built testing framework which can be used to test our own products. Clarity is still under development. I will talk more about this framework in one of my future posts.

All the tests that we are writing is submitted as patches to the public jira project 'Test Automation'. Our team lead take a look at that and apply them to the main trunk/branch as we are not having committer rights. I will elaborate more on this jira thing and patch submission in my future posts.

We have to adhere to the standard coding style that is used in wso2. I have posted on this matter earlir in this blog. How to use the style xml to configure eclipse. You can find that post here. We used the remote debugging that is available in the IDE to test or patches. You can find my article on remote debugging here.

This was a nice learning curve for all of us. We went through lot of training sessions and was informed with best practices when testing, which were great additions to our knowledge. And it was a new place I was in 59 branch and now I am in 58 branch. And I must mention that here the TT table is far better than what we had in 59. After all this is temporary, I will return to the 59 after this test automation thing is done.