What’s that you say - you’d like to learn more abo...

# power-assert

[dmcg]

What’s that you say - you’d like to learn more about power-assert but can’t find any video content anywhere and JetBrains haven’t gotten round to publishing the KotlinConf presentation?

https://youtu.be/ujxNvC_Q_cA▾

[bnorm]

This is wonderful! Thank you for promoting power-assert!

Wanted to provide some insight on a few things you noted during the video:
1. The extra values you are seeing on the expression app.loadStockList() are indeed the implicit receivers. If you would like to open an issue about that we can look into either ignoring implicit receivers or explicitly labeling them.
2. In your example with valueOrNull?.items?.size ?: 0 on the right hand side of a comparison where you didn't get any nested values, I think this is due to the elvis operator. Would appreciate an issue being opened for this example, as we should be able to handle it better.
3. Multiline toString() of values within the expression are indeed a display problem. The message template is built at compile-time, so there isn't any special handling of more complex values. This can make the display rather ugly in these cases, but we have some plans in this area: https://youtrack.jetbrains.com/issue/KT-66807. You are welcome to open a separate issue though if you have ideas on how we could better handle this specific case.
4. For boolean short-circuiting, if the conditions don't relate to each other but you want to combine them, you can use the and and or boolean infix functions (instead of && and ||) which do not short-circuit. (Note: you may need to add some () in the right places to get things working correctly)
5. For the soft-assert example, the sample assertSoftly code could be updated to also display successful assertions as well. The assert function is always called with the call diagram. So it is really up to the called function to decided what to do with the call digram (message of exception, log to stdout, etc). This could allow successful assertions to be displayed as well when there is a failure for Strikt like behavior.
6. And finally, my general recommendation is use assertEquals whenever possible and assertTrue as a fall-back for more general checks (both configured for power-assert, of course). This ordering gives you the best IDE integration for diffs.

[dmcg]

I’ve been following the project for a while, so it’s good to get it to a wider audience. Although I guess my audience will be smaller than yours as soon as the KotlinConf video is published.

[dmcg]

Thanks for the tips. I hadn’t thought of using it for assertEquals, or just to get the diagram, will follow that up this week.

[dmcg]

This for multi-line strings?