Learning bLog

You want to test what your application logging and you don't know how to do that in simplest manner, well we've logback to rescue. (If your using slf4j but with other than logback as a implementation, then you have to add logback as a test dependency with logback.xml in src/test/resources) One (not exactly) caveat is that, for testing logs using logback we need to use Mockito for creating mock Appnder and asserting for the exact log string in argument. Here is the actual code- 1. Create a base test class for log testing. public abstract class BaseLoggerTest { final Appender mockAppender = mock(Appender.class); @Before public void setup() { when(mockAppender.getName()).thenReturn("MOCK"); (ch.qos.logback.classic.Logger)LoggerFactory .getLogger(ACCESS_LOGGER_NAME)) .addAppender(mockAppender); } protected void verifyLog(final String expectedLog, final Level level) { verify(mockAppender, atLeastOnce()) ...

We always have some good programmers around us who are capable of doing work at hand, but to success in long term we need better programmers. Here are some traits I found important to become better programmer. Good programmer start coding right away after picking up the task, better programmer first do some little design upfront (may be draw some UML, flowcharts etc), write the simplest readable tests first and then write minimum production code which makes that test pass. Good programmer stick to the tool, framework, workflow he/she knows best, better programmer keep the affinity towards any technology aside and evaluate and use the best possible tool, framework available.  Good programmer focuses on working code, better programmer too focused on working code but also gives the utmost importance to code readability, flexibility and other design principles . Good programmer ever read technology books when he/she was in college, better programmer subscribed to feeds, question...

Problem: There are cases when you want to test whether two objects are equal, mean did they contain same state or not ? This occurs mostly when you're trying to test JAXB generated beans or any VO/DTO which doesn’t' implement Object#equals() method or/and whose source code you can't modify . Solution: I knew there is a class (Commons lib's EqualsBuilder class) available which "reflectively" creates the equals method for you taking care all the rules for writing good equals method. But that class doesn’t have a method to test whether two object are equal or not. At back of my mind, I know Mockito library internally uses the same commons class to solve my problem. I quickly scan the mockito jar and found this class. Here is the code snippet for the same (please note, you have to add mockito jar on classpath for this) import org.mockito.internal.matchers.apachecommons.ReflectionEquals; . . . public <T> void assertObjectEquals(final T expected, final T...

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.