How to adjust string representations

[SerVB]

I see Atrium uses a non-trivial string representation for objects, like adding identity ID to the object (<1619356001>).

What if I want to customize it, is it possible or is it hardcoded inside the framework?

[robstoll]

It's not hard-coded and its possible to exchange the current implementation with yours. You need to replace the current implementation of ch.tutteli.atrium.reporting.text.TextObjectFormatter with your own implementation.
If you want that only for one use case then you can use

expect(...).withOptions {
  withComponent(ObjectFormatter::class) { c -> ReadmeObjectFormatter(c.build()) }
}.toEqual("Another string")

If you intend to exchange it all the time then I suggest you use your own expectation verb: https://github.com/robstoll/atrium#use-own-expectation-verb see also readme.examples.OwnExpectationVerbSpec for an example.

just as info, I started refactoring the output and there we won't see the object identity any more, it will only show up when equals is used behind the scene as additional hint. But to be fair, I started that somewhere in Q1 of this year, switched then to the MPP migration and sadly don't have enough time currently to push that forward.

Anyhow... I am curious, how do you want to change the string presentation?

[SerVB]

The classes we considered were our data classes. They had many properties so their toString was overridden to contain only selected properties. Moreover, toString is usually single-line.

For tests, we wanted to just output pretty-printed multi-line JSON of all the internal fields. Makes diffing visually easier, IMO. Simply via jackson, for example:

// just copy-pasted an example in Java, but should be adjusted a bit; same can be done in Kotlin ofc
ObjectMapper objectMapper = new ObjectMapper();  // todo: setup multi-line pretty printing
Car car = new Car("yellow", "renault");
objectMapper.writeValue(new File("target/car.json"), car);  // writes {"color":"yellow","type":"renault"}

robstoll/atrium-roadmap#39 looks promising! If the IDE allows to view the diff interactively, it's very convenient.

[SerVB]

In this case, it could be data class Car(val color: String, val type: String) with toString implemented like "$color $type". But for visual comparison, it's better if the fields are output on different lines, so pretty-printed multi-line JSON works well for this:

{
  "color": "yellow",
  "type": "renault"
}

[robstoll]

Thanks for the additional feedback. I see where this is going. I intended to implement a per property report for data classes at some point but unfortunately did not find the time (and apparently my need for it was not big enough). So for something like:

expect(Car("yellow", "VW")).toEqual(Car("yellow", "renault"))

You would see the following in reporting (only properties which failed are reported):

I expected subject: "yellow renault"          com.example.Car<12345>
-> type:     "VW"
   to equal: "renault"

Would this behaviour also be helpful in your real use cases?

And a second question, if you have such big data types, do you always want to compare all properties (i.e. via toEqual of the data class) or sometimes ignore a few?

[SerVB]

Would this behaviour also be helpful in your real use cases?

I don't know... I just got used to a diff in the IDE that I can invoke for many other assertion libs:

And a second question, if you have such big data types, do you always want to compare all properties (i.e. via toEqual of the data class) or sometimes ignore a few?

With assertJ, it's possible to ignore fields easily. I think it's a useful feature:

  val expected = User(name = "John", age = 25, children = listOf("Alice", "Bob"))
  val actual = User(name = "john", age = 23, children = listOf("Bob", "Alice"))

  @Test
  fun `recursive comparison`() {
    assertThat(actual)
      .usingRecursiveComparison()
//      .withComparatorForType(DoubleComparator(1e-2), Double::class.java)
//      .withComparatorForType(DoubleComparator(1e-3), Double::class.javaObjectType)
      .withComparatorForFields(compareBy<String> { it.lowercase() }, "name")
      .ignoringCollectionOrder()
      .ignoringFields("age")
      .isEqualTo(expected)
  }

One of the obvious disadvantages of assertJ here is that it's very dynamic: string literals are used to refer to names, not references.

---

Anyway, I think it's better to ask a real user of Atrium for opinions...

[robstoll]

Thanks for you Feedback, also valuable from a non-Atrium user 👍