new feature for non-string reflection evaluation, similar to "extracting"

[assertj]

new feature for non-string reflection evaluation, similar to "extracting"

[joel-costigliola]

Hi,

That could an interesting thing to be able to call a method on each objects of the collection under test.
Do you have any concrete use case on your mind ?

I think the syntax is too heavy, it seems to me we are loosing the focus on assertions because of the plumbery needed to call method, we are repeating the class (TolkienCharacter.class) as we can deduce it from the type of elements in the collection, I was thinking to the following syntax :

assertThat(fellowshipOfTheRing).calling("getName").contains("Gandalf", "Frodo", "Legolas");

I know it is String based and its is not refactoring friendly but is has the big advantage to be light, maybe we could offer both.

Have you any idea of a lighter syntax that would be refactoring friendly ?

Your comment on type safely is right but it is not a big usability problem according to me, it can even be a problem, let's say your are extracting Employee from the collection (Employee inheriting from Person) then contains will wait for Employee only. But what if your expected objects are declared as Person but actually are Employee, then you cant' use them in contains even though they are true Employee.
Anyway this is a minor issue to me, and I'm not quite sure if type safety is really worth it.

Thanks for the idea,

Joel

[welkman]

As far as a use case, I was considering it especially as an alternative to extracting that didn't require Strings.
As far as alternatives that don't require the class to be provided, that is not possible because of type erasure. An actual class is required for the mechanism behind the scenes which would basically proxy the class so that you can capture the method you want to invoke repeatedly, by invoking it once on the proxy.

Using the same syntax as I suggested, you could extract out the part that declares the class. It doesn't eliminate the "problem", but rather moves it. This takes a little of the sting out of the actual assert statement, and it could be reused for multiple asserts that way:

TolkienCharacter callsTo = call(TolkienCharacter.class);

assertThat(fellowshipOfTheRing).evaluating(callsTo.getName()).contains("Gandalf", "Frodo", "Legolas");
assertThat(fellowshipOfTheRing).evaluating(callsTo.getRace()).contains(Race.hobbit, Race.elf);

I will have to consider further your comment about the supposed limitations of enforcing type safety, but my first impression is that there is that your example possibly suggests a code smell (in either the test or the code under test) which I haven't put my finger on yet. If I get some time I will return to elaborate your suggested test case to see whether my concern is founded.

[joel-costigliola]

It is true that you can't know at runtime the type of list elements but if you are using introspection to call method then you don't need it, you just expect that the method exists in each collection elements.

An example of generics drawback to makes my point clearer :

  @Test
  public void generics_limitation() {
    Employee martin = new Employee("Martin Fowler");
    Employee kent = new Employee("Kent Beck");
    List<Employee> employees = newArrayList(martin, kent);
    // now let's declare Martin as a Human (Employee inherits from Human
    Human martinAsHuman = martin;
    // this line compile
    assertThat(employees).contains(kent, martin);
    // this one does not compile because contains expects Employee not Human !
    assertThat(employees).contains(martinAsHuman);
  }

the last assertion does not compile because contains, which is generic, expects Employee not Human even though we know by construction that martinAsHuman runtime type is Employee.

[joel-costigliola]

Extracting can be type safe thanks to #222.