[JUnit] Testing only few fields of two POJOs in Junit using Mockito

[Sangel Kapoor]

I am testing two Pojos as follows

  assertThat(actualPojo, new ReflectionEquals(expectedPojo,excludedFieldsFromCheck)); 

but what I am trying to find is not to mention fields that I want to exclude but fields which I want to include. Is there any way ??

[Junilu Lacar]

I smell a test smell; possibly a design smell, too. What's your motivation for using ReflectionEquals?

[Jeanne Boyarsky]

I agree with Junilu.

Also, if you know the fields you want to compare, why not just call their getters?

[Sangel Kapoor]

Task : I am  converting external request to Service to Internal Command.  So essentially I need to test the quality of two POJOs  and I need to test the quality for few fields only.

I agree I can write getters but they are many.

There is another option to use Matchers SamePropertyValueAs , but it does not provide any fields to include or exclude. This was the motivation to switch to ReflectionEquals.

[Junilu Lacar]

I still don't get what you really need to do. You are explaining in terms of implementation details, we are asking about intent.

It's the difference between saying "I want to iterate over an array and add each value to variable x" vs. "I want to calculate an average speed flown during all runs."

You are telling us the former while we are looking to understand the latter.

[Sangel Kapoor]

So intent is to check whether transformation of one Pojo to another pojo is done correctly. Essentially I am testing static transformer method which converts one pojo to another.

[Junilu Lacar]

So, if you only care about certain fields that you want to explicitly list out, why use reflection?  That's the smell. Using reflection to exclude specific fields makes sense because you won't have to change the code if that exclusion list doesn't change but the objects are modified to include more fields that should be checked. In your case, it doesn't make sense to use reflection because you want to list fields to include.  If that list changes, you'll still have to change the code. You gain nothing by using reflection. Since reflection is costly, you're paying for a service that is of no practical use to you in the context of the problem you're trying to solve. That's like paying for premium cable channels that you don't ever watch.  So what's the point?

[Sangel Kapoor]

Junilu Lacar wrote:So, if you only care about certain fields that you want to explicitly list out, why use reflection?  That's the smell. Using reflection to exclude specific fields makes sense because you won't have to change the code if that exclusion list doesn't change but the objects are modified to include more fields that should be checked. In your case, it doesn't make sense to use reflection because you want to list fields to include.  If that list changes, you'll still have to change the code. You gain nothing by using reflection. Since reflection is costly, you're paying for a service that is of no practical use to you in the context of the problem you're trying to solve. That's like paying for premium cable channels that you don't ever watch.  So what's the point?

Got your Point, thanks a bunch ! and I think for the same reason they don't have include fields in api but exclude fields only.