https://kotlinlang.org logo
Join Slack
Powered by
<@UFGCACPE0> A little thing to consider, if a reso...
# opensavvy
d
@CLOVIS A little thing to consider, if a resource file is very large, and a 
prepared { }
is used, it'll just pour the whole file content out to the test console... that might not always be the behaviour the user wants... I didn't see any prepared setting that would suppress or concatenate that..
c
Hehe that's true. Would ‘only print the first line’ be a valid behavior for you?
d
Maybe in some cases... in this case it's an rss feed, so the first line will always be 
<xml...>
... doesn't say much... This issue is probably with not only resource files, but any 
prepared { }
, that would result in larger output...
Maybe have a parameter for some kind of output formatter that would by default try to print everything up till a certain reasonable limit?
c
Actually, since they can only be printed in the context of a test, this could be a TestConfig 🤔
It would apply in the exact same way to all Prepared values in a single test though
Btw: the reason it can't be an optional argument to the 
prepared
function itself (would be more convenient for everyone) is that that would be a binary-breaking change
d
That's another little issue, I currently find those TestConfigs to be pretty verbose and hard to find (each one is it's own class?)... But that aside, maybe when calling the prepared, it could have an outputter param...
Copy code
suspend operator fun <T> Prepared<T>.invoke(outputFormatter: OutputFormatter): T = ...
but that would require putting that parameter at every call and not forgetting it... 😵‍💫
Maybe 
preparedFormatted(...) { }
?
c
That's another little issue, I currently find those TestConfigs to be pretty verbose and hard to find (each one is it's own class?)...
Yeah. Currently the best way to find them is in the package-level documentation: https://opensavvy.gitlab.io/groundwork/prepared/api-docs/suite/opensavvy.prepared.suite.config/index.html They work basically the same way as CoroutineContext, to allow anyone (or any test runner) to create custom config, and to avoid breaking changes when configs are added
But that aside, maybe when calling the prepared, it could have an outputter param...
The value is only printed on the very first use though, so for every other use it's useless And the very idea of prepared values is that you don't care which one is the first use (since they can depend on each other)
Please vote for https://youtrack.jetbrains.com/issue/KT-8214/Allow-kind-of-vararg-but-for-data-class-parameter#focus=Comments-27-10082733.0-0. With this, I could add it as an optional parameter without having to worry about backwards compatibility
👍🏼 1
d
And the very idea of prepared values is that you don't care which one is the first use (since they can depend on each other)
Yeah, that's why the best solution is at declaration point...
to create custom config, and to avoid breaking changes when configs are added
That's for sure an advantage... but for those that don't know all the options, they're pretty hard to find and to use different settings for each test could be very verbose. It might be nice to group them somehow under a 
object TestConfigs
with functions or extension functions for each? Or maybe have common combined settings in one of those functions as parameters? 
fun TestConfigs.set(ignored: Boolean = false, timeout: Duration = ..., vararg tags: String)
It could be that having another named variation of prepared (or overload?), and keeping the old one around delegating to the new one and making it deprecated might keep binary compat?
c
That would work, but I'm going to need to do that cycle each time I add a new option, and I have to keep all the old ones....
d
Yeah, I voted for that feature, but we don't know how long it'll take to implement... I understand that this might not be worth all that trouble... maybe there could just be a preparedFormatted variant...? But if anyways you might have had other things to add there...
c
If you create an issue for it, I'll do the overloads solution for now
👍🏼 1
d
Maybe another possibility... you could maybe add a 
setFormatter(...)
to the TestDsl just like you have 
cleanUp { }
, would that work?
But I guess that wouldn't be for only that prepared... 😞..
c
That sounds more complex than using the TestConfig
d
Why? TestConfig isn't in the prepared block, it needs to be set on every test
The thing is that there's no PerparedDsl scope...
c
You can also set the TestConfig on a suite directly to inherit it to all your tests
d
For all prepareds... we need for only a particular one.
c
there's no PreparedDsl
Yeah. I hesitated a lot. In the end, I decided not to have one, so it's clearer that 
prepared
is just a way to declare a part of the test outside the test
I mean, I'll do the overloads solution. I think it's the best one here.
👍🏼 1
d
Yeah, I was just thinking that a PreparedDsl would be the closest to be open to changes without binary incompat... (maybe even as the 
it
in the prepared block, since the receiver is already TestDsl), it would only be a one-time migration deprecation... but the question is, how much more would there be to add to prepared?
So if this is really the only case, the previous solution would be best, as you said.
c
I can't really think of a single thing that makes sense in 
prepared {}
but doesn't in 
test {}
IMO it's nice that they behave 100% the same
d
Where were you thinking of adding that Display<T> @CLOVIS?
Oh... in the Prepared class...
c
i wanted something like:
Copy code
fun <T> prepared(
    …,
    display: (T) -> String = { it.toString() },
    block: TestDsl.() -> …
) …
but I can't because of the 
T
variance being different.
d
What do you think about just using Any like I commented in the issue?
Open in Slack
PreviousNext
Powered by