How to avoid strict stubbing argument mismatch in java

I have an object like

@SuperBuilder(setterPrefix = "set", toBuilder = true;
class Person {
  private final String name;
  private final boolean active;

}

I use this object in a method like

public SomeType doSomething(Long id) {
   Person person = personService.getPersonById(id);
   Person updatedPerson = updatePerson(person);
   validationService.isValid(updatedPerson);
    ......
}

private Person updatePerson(Person person) {
  person.toBuilder()
        .setActive(true)
        .build();
}

But when I test this method I get a strict stubbing argument mismatch

void test() {
 Person person = Person.builder()
   .setName("Name")
   .build();
 Person updatedPerson = Person.builder()
   .setName("Name")
   .setActive(true)
   .build();
when(personService.getPersonById(1L)).thenReturn(person);
when(validationService.isValid(updatedPerson)).thenReturn(false);

.......

Can someone tell me how to avoid this problem- and create a correct argument?
Thanks for any help!

You have 2-3 options for solving this issue. The easiest solution would be to simply override the equals method from the Person class (or simply add lombok's @EqualsAndHashcode - but this will affect your production code (not only the test itself).

Alternatively, you can use a more generic Mokito matcher here are some examples that would work:

// check solely based on name/active fields
when(validationService.isValid(
      ArgumentMatchers.argThat(p -> p.getName().equals("Name")))
  )
  .thenReturn(true);

// or
when(validationService.isValid(Mockito.any(Person.class)))
  .thenReturn(true);

// or simply
when(validationService.isValid(Mockito.any()))
  .thenReturn(true);

Lastly, if validationService is not doing any I/O, you can try to write the code/test in such a way that mocking it is not necessary. In other words, if validationService.isValid(p) is just checking some state, maybe you can use the actual object and decide from validationService whether to return a valid or invalid Person object.

In my opinion, the fewer mocks the better... I would personally try this last approach if possible.