renatoathaydes
commented
1 year ago Hi @Gleethos . I don't believe this to be a problem with Spock reports itself.
Where blocks are represented as tables of data in the reports, not source code, and I would like to keep it that way. In my opinion, which you are free to ignore, it's not nice to use lambdas as examples in tests. Examples are meant to be pure data. That ensures tests stay simple, and reports are clear.
You may ask how could you avoid using lambdas as examples in your tests, which is a valid question.
I have the following strategy, normally, and you can probably come up with others...
- Create an enum which abstracts away the logic to be tested.
- Most of the time, it can implement a 'native' interface like
java.util.Functionor some custom interface to make it monophormic. - In your example case, something like this:
def 'my tests'( Function<MyThing, Object> example ) {
given:
def myThing = new MyThing()
when: 'something'
example( myThing )
then: 'error'
thrown expectedException
where:
example || expectedException
Examples.OnlyPositive || IllegalArgumentException
Examples.NoNulls || NullPointerException
}
enum Examples implements Function<MyThing, Object> {
OnlyPositive, NoNulls; // more
@Override
Object apply( MyThing myThing ) {
switch ( this ) {
case OnlyPositive:
return myThing.onlyPositive( -1 )
case NoNulls:
return myThing.dontLikeNull( null )
default:
throw new IllegalStateException( "Case not covered: $this" )
}
}
}
Gleethos
This is a problem because certain data table entries will become unreadable when turned into reports because
toString()often distorts their representation.Consider the following example:
So when I try to make this into living documentation using the data table entries using the
dataValuesin my template file:I get something like this:
However, what I really want is this:
I understand that this is not what the
dataValuesis for, what I would expect is that there is the actual code of thewhereblock in theblock.sourceCodefield, but it is always missing! After looking into the code I noticed that there is a simple condition preventing the where block code from being read, I removed it and it worked perfectly well.I would be happy to fix this if that's okay, this would not change anything except it would open up more option for users. This is particularly interesting to me since we are using this plugin to generate test suite browsers for pure documentation purposes so that newcomers can learn how to use our libraries and APIs without having to dig through the source code files...