Learning bLog

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

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