A Day of Innovation: TomTom Pune DevDay 2013

Friday (6 April 2013) was a day of innovation and engineering, fun and quiz, it was a first TomTom Pune Engineering DevDay.

Key Highlights of the day:

• Kick started with U2 public concert video, a good way to wakeup people.
• Many speaker talked about how we can extend and experiment with our new generation map editing tool Cartopia
• I talked about function programming and how we can achieve it using Scala.
• There were coffee breaks with testers which showcase some really cool technologies like puppet, test automation using FlexPilot and risk based testing's.
• Day end with exciting quiz, prize distribution and beer :)

If you want to be a part of next TomTom devday, join us http://www.tomtom.jobs

Adjustable flex datagrid row height for multi-level tree component

Note: This blog is extension to the post blogged here, the OP has used one level tree to display in grid, whereas I used multilevel tree.

From last 2-3 months I'm working on Flex, developing our in-house map editor. We've a requirement to show a grid with some column containing multilevel tree data, I googled it and found the above link which was matching to our requirement but got one problem, it didn't work correctly for multilevel tree. The problem is -

• It failed to adjust height when you expand inner child element.
• The whole tree get collapsed when you collapse the inner element.

To provide a solution to above problems, you have to -

• Keep a flag which tells if root is closing or not, if root is closing keep the original height.
• For all other child expansion, count the children from existing "open items" and adjust height accordingly.

The below code explains it all.

Tests your logs using logback

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())
        .doAppend(Matchers.argThat(new ArgumentMatcher() {

            @Override
            public boolean matches(final Object argument) {
                return ((LoggingEvent)argument).getLevel().equals(level)
                    && ((LoggingEvent)argument).getFormattedMessage()
                       .contains(expectedLog);
            }
        }));
    }
}

2. Extend logger base class to verify actual logging

public class MyClassLoggerTest extends BaseLoggerTest {

    @Test
    public void testLogSomethingShouldLogSomething() throws IOException {
        // given
        MyClass object = new MyClass();

        // when
        object.logSomething();

        // then
        verifyLog("I just logged something.", Level.INFO);
    }
}

Simple.

Good Vs Better Programmer

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.

1. 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.
2. 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. 
3. 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.
4. Good programmer ever read technology books when he/she was in college, better programmer subscribed to feeds, question/answers on technology forum and sometimes blogs.
5. Better programmers embrace the test pyramid and write unit, integration and UI/acceptance tests in order to flag given task as delivered.

You can certainly guess that better programmers are no one but Agile Programmer. The list is not limited to this only. There are other stuff you want to read to learn more about better programming, like 97 Things Every Programmer Should Know
Update: I came across DZ article which speaks what I was trying to cover here.

How to test objects equality if they don't implement Object#equals()

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 actual) {
     assertTrue(new ReflectionEquals(actual, 
                                    (String[])null).matches(expected));
}

This why Mockito is so famous, it makes your testing easy especially with mocks.

PIT Tests, a Mutation Testing

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 < 5)
   return "hi";
else 
   return "bye";

Consider you write tests for it, and all are passing. Now, when pit tests executes over such tests, they mutated to this runtime as

if ( i < 5) // operator < mutate to <=
    return "hi";
else 
    return "bye";

And tests are rerun over such mutated code, if you really test such methods for boundary condition; everything will be good otherwise bug will occurs.

There is few default mutators that are applied while mutation testing using PIT.

That’s all, give it a try and see if its suits in your organization culture ;).

What’s missing?

Only thing I felt that need to improve for PIT tests are the HTML report visibility, the report doesn’t clearly states how many test got the problem, means how many tests are killed and how many are survived. I think this info should be aggregated on index page.

Not 10, but 6 things about jMeter

I list down some "good to know" things about jMeter. Hope it helps you while considering the jMeter scripts design, development and execution.

1.  Its open source Java tool for functional and load testing.
2. Can be "extended" to create new sampler, controller etc.
3. 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.
4. 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.
5. 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/
6. 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.programmerplanet.org/pages/projects/jmeter-ant-task.php The same site also got one XSLT for transforming your JTL (jMeter log of sript execution) to HTML report. 

I''ll update this list as I explore jMeter more!