What I’d like to explore in particular is using Ha...

# minutest

[dmcg]

What I’d like to explore in particular is using Hamkrest or Strikt or Atrium some other assertion lib to write self-describing Then clauses / @natpryce @robfletcher @robstoll

[robstoll]

I am quite busy at the moment due to Hacktoberfest; I am coming back to
you mid November. What exactly is your goal? I guess there is more than
just using Atrium, right?

[christophsturm]

that sounds interesting, what do you have in mind?

[robfletcher]

also curious to understand more

[christophsturm]

so each then block only asserts on one field and you connect them with and?

[dmcg]

Not necessarily- the last Then in the example is a check on the whole fixture, composed with Hamkrest feature extraction.

[dmcg]

I suppose it would depend on what read and allowed reuse of assertions better in different circumstances

[christophsturm]

so in

expectThat(subject)
  .hasLength(35)
  .matches(Regex("[\\w\\s]+"))
  .startsWith("T")

you just replace expectThat with Then

[dmcg]

I think in that case it could be Then(“subject”, Fixture::subject).hasLength(...)...

[dmcg]

Some combination of the name of the subject, how to extract it from the fixture, and a matcher for the type

[christophsturm]

in expect when then you only assert on the fixture?

[robstoll]

should the report include the assertion even in case the test passes?

[dmcg]

@robstoll I’m using the description of the matcher to generate (part of) the name of the test, so yes

[dmcg]

@christophsturm given.then just has the fixture, as given should only be setting up the fixture.

[dmcg]

When.then has the fixture and the result of the then. In the Hamkrest example I’ve split it into when.then, which checks the fixture, and when.thenResult, which checks the result of the when block

[robstoll]

I guess the integration of Atrium heavily depends on the desired reporting. For instance, what would you expect if the Fixture is a person and the assertion would be something like feature { f(it::children) }.all { feature { f(it::age) }.isGreaterThan(18) }

[christophsturm]

the autogenerated test name is very verbose IMO.

[dmcg]

@robstoll Can Atrium generate a description of the assertion like Hamkrest?

[robstoll]

not in the same way but yes

[dmcg]

@christophsturm the name is verbose, although thinking this through, each scenario generates a context and a single test, so in the output you have the scenario name as the summary, and the test name as the details. I wonder if it’s better to just generate a single test with the scenario name though? In which case the assertion description is moot.

[dmcg]

@robstoll what would the description for your assertion look like? Would it read ok in a clause ‘Then person ${assertion.description}’ like the Hamkrest one does?

[robstoll]

it is not intended for single lines, it would read more like:

expect Person(...)
◆ children
  ◆ all entries: 
    » age
        ◆ is greater than: 18

[robstoll]

expect could be replaced with Then of course

[robstoll]

It could be formatted as single line though but depending on the assertion it will be hard to grasp I guess and would kind of limit the user to make one single assert statement

[dmcg]

Gotcha. I see with both Atrium and Strikt that the nice layout spoils the single sentence. Maybe I need to stop thinking about using the assertion in the test name and start producing detailed output separate from the test run, as with https://github.com/dmcg/konsent

[robstoll]

Atrium is flexible enough and could produce single sentences but the phrasing is more of a problem I guess, depending on how complex zhe assertion is. The above could also look like

Then person, its children for all age is greater than 18

Which reads so so, kind of OK
But what do you do if you want to make the additional assertion that none { isGreaterThan(65) } ? Repeat the whole phrase or come up with some sort of grouping? Finally you end up with something similar to Atrium 😉

I plan to integrate Atrium with test runners but in a different way. I would not only describe the assertions but also show the result

[robstoll]

It will look more like konsent in the end