Learning bLog

While wondering over internet, I just come across the "mutation testing" and here I blog about it. The blog largely said about one such framework " PIT tests ". When we say my code coverage is 80%, that only mean, in simple term, your unit tests cover 80% of your code base. Do they really tell you what your tests are really testing? - No. To answer this, there is a thing that called as "mutation testing". The framework I am talking about is PIT tests; they said it’s like automation tests for your tests. Cool! How does it work? Well in plain simple language, it mutate (modify the byte code at runtime) some logical part, decision taking part of your code and then run tests against such modified code, if your test fail (called as mutation killed), your test is OK, if its passed (called mutation survived), beware, there might be some bug hidden there. So, more the mutation killed more good your tests are. Example: The simplest example might be, if ( ...

I list down some "good to know" things about jMeter. Hope it helps you while considering the jMeter scripts design, development and execution.   Its open source Java tool for functional and load testing. Can be "extended" to create new sampler, controller etc. Module Controller - If your scripts are going heavy and you found many copy-paste steps; in that case just create a module of those steps. Module is like a function in programming. Include controller - Some modules are global and can be used in many scripts, in that case just include that JMX into your main JMX, like you include JSP tag. Parameterized Controller - Third party controller which enable us to pass various runtime parameters to sample. Usually sits on top of module controller. http://code.google.com/p/jmeter-plugins/ jMeter scripts can be executed from ANT, it help in automating the daily execution of scripts. (Can be triggered from nightly build process from your CI server): http://www.pr...

In case you trying to access the VM arguments in spring application context, then just add the below bean definition in context file: <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="ignoreUnresolvablePlaceholders" value="true"></property> </bean> And access the VM args as ${vm_property}, e.g if you passed the –Dfoo=bar, which can be access as, <bean class="com.company.test.MyClazz"> <property name="myProperty" value="${foo}"></property> </bean>

Being a firefox fan, I just updated my current FF (3.6.x) to FF 4, everything goes well and I could see much improved FF both performance and UI wise, but I couldn't use selenium IDE with it (Yes, some time I do UI testing), so after some googling found 2 solutions: Solution #1: If you already have the selenium installed but its disabled because it's not supported by FF 4 yet, the fix (hack) is explained here (See Mark Collin reply) Solution #2: If you don't have selenium IDE installed, then simply download the latest supported but not yet released selenium IDE installer from here and install it just by dragging or opening it to FF window.

TDD, I'm practicing development using unit test from 1 year now and frankly speaking I'm loving it. I listed some points/notes/importance I learned from TDD. You might like to add some points or want to correct me, so please comment. Here the list goes: Caught 80% of bugs at first place before your code goes to production. Explore and forces to think the development and design in proper Object Oriented way, means less class dependencies, loose coupling's, SRP etc. You can fearlessly do refactoring and enhance the quality of existing code if you have enough unit test code surrounding. If you have been reported any bug/issue in production code, write the unit test that produce that bug and fail(red), then fix the code(refactor) and ultimately make the unit test to success( green). Gives idea about the usage of API you're developing. I know this are not the only points which make TDD incredibly great practice, but I'll update this blog for some more points as...