Introduce global precision for Local/ZonedDateTime?

[robstoll]

I had the following use case:

• ZonedDateTime was stored on a db with a precision for milliseconds
• comparing this against an expected ZonedDateTime required that I had to truncate the expected ZonedDateTime

In case one encounters such a use case a lot, then one would probably start to have own assertion functions doing the truncation.

Instead we could provide a config for expect where one can choose to set the precision for expected Local/ZonedDateTime so that a user only has to define its own assertion verb but than can use all functions and the truncation happens automatically.

Thoughts?

[jGleitz]

I, personally, am very cautious about configuration options. I think it is super important that test code remains easy to understand. Having a property that is set one way in one project I work on, and another way in another project sounds like a source for misunderstandings and bugs to me.

Your proposed solution suggests a general pattern for atrium: I can set some configuration options and activate them by using a special assertion verb. As I understand it, code using this pattern would in reality look like this:

myExpect(dbDate).lessThan(startDate)

Where myExpect activates five special options that are relevant to the project. My point is: Nobody will call this expectWithLessZonedDateTimePrecisionAndFeature2AndFeature3AndFeature4AndFeature5. In other words: Whoever reads the code cannot be aware of how myExpect works.

I think a better pattern would be this: We make it very easy for projects to define their own assertion functions that can have telling names. For example, if we can configure the precision on the assertion function level, projects can define their own assertion functions:

expect(dbDate).lessThanWithLittlePrecision(startDate)

This has some more overhead, but not too much. And I think it makes it much easier to write readable code.

[robstoll]

Thanks for your feedback. I think you are right that it would be strange if the assertion behaviour as such changes for a function based on a configuration. On the other hand, I will most likely go with this approach for reporting related stuff

As I understand it, code using this pattern would in reality look like this:

myExpect(dbDate).lessThan(startDate)

I would expect it to look like the following (that's what I do in any case):

import com.mycompany.atrium.expect

expect(dbDate).isBefore(startDate)

I'll close this issue and not proceed with this idea