Learning bLog

Writing an integration test which test end to end flow of your application can become cumbersome activity if you really hitting real db and services. The best way to mock, test double your external dependencies and thus speed up your test execution. I created a dummy map-service project which demonstrate about writing maintainable and speedy integration tests using mocking, test double pattern, spring and automating them using maven and jetty. You can find the project at my github location: https://github.com/sagarr/maps-service Here are some code snippets explaining the important steps in configuring your project. POM - Configure jetty for deploying your app and running tests against it. . org.mortbay.jetty jetty-maven-plugin ${jettyVersion} /${project.artifactId} 8005 STOP 5 true 8080 60000 start-jetty pre-integration-test run 0 true stop-jetty post-integration...

Recently, I started exploring and learning Scala and functional programming. So far, it is a good experience and as a programmer gives you new "functional" thought process about problem. The best way to learn Scala or any language for that matter is to start writing Katas in that language. Coding Kata, if you're not familiar with it then must visit codingdojo.org . In short, coding kata is programming practice mostly done in TDD way, which makes you better programmer. BTW, If you're wondering where are my katas in Scala, you can find them here: https://github.com/sagarr/scala-dojo

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

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.

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...