This is awesome, not just for test set but in main as well. I like to have a const val DEBUG boolean value that will do compiler time code elimination for all assertions in main code. This would let it print really useful fast fail errors when running in dev, and get rid of all that magic in prod.
@@Amejonah no its already in the language, if you define a final bool DEBUG and put some if statements behind that flag, then if its false at compile time then all those assertions behind those ifs just go away from the bytecode entirely... that allows you to enable or disable assertions depending on environment and have it completely erased from the bytecode if you desire performance...
Ironically I think that it’s in production that this technology will be most useful. When we write tests we usually know what failures we are looking for, but when an assertion fails in production it is by definition unexpected, and at that point we want to know as much as possible about the values that caused the failure.
@@PairingWithDuncan yes, i often leave assertions on in prod, if you do it right assertsions should not change behaviour of the system, and if you do not abuse them performance impact is amortised and very low. I only keep the option to disable them behind that if(DEBUG) so i can removed them if necessary, but its not necessary for the most cases. TigerBeetle team does the same, but no option to disable assertions. Very cool library, gonna use it for sure.
This is awesome, not just for test set but in main as well.
I like to have a const val DEBUG boolean value that will do compiler time code elimination for all assertions in main code. This would let it print really useful fast fail errors when running in dev, and get rid of all that magic in prod.
Yes, a dev/release build system would be really nice!
@@Amejonah no its already in the language, if you define a final bool DEBUG and put some if statements behind that flag, then if its false at compile time then all those assertions behind those ifs just go away from the bytecode entirely...
that allows you to enable or disable assertions depending on environment and have it completely erased from the bytecode if you desire performance...
Ironically I think that it’s in production that this technology will be most useful. When we write tests we usually know what failures we are looking for, but when an assertion fails in production it is by definition unexpected, and at that point we want to know as much as possible about the values that caused the failure.
@@PairingWithDuncan yes, i often leave assertions on in prod, if you do it right assertsions should not change behaviour of the system, and if you do not abuse them performance impact is amortised and very low.
I only keep the option to disable them behind that if(DEBUG) so i can removed them if necessary, but its not necessary for the most cases.
TigerBeetle team does the same, but no option to disable assertions.
Very cool library, gonna use it for sure.
wow, and this is just the start of K2 😮
For the record the plug-in is also available for pre-2.0 compilers
I know from the start that the first example of presentation will be so relatable.
assertEquals? AssertSize AssertEmpty etc?
This technology is indistinguishable from magic!
Wow. I guess now there is no excuse to not write tests. Thank you, Power-Assert!
4:36 That's Cool!!
Finally, an argument for people sticking with Spok (which is waaaaay too magical) and it's assertion messages
That's amazing, but I'd rather not see the word Java.
When will it be possible to do tests on pure Kotlin?
You can now, but I’m interested in why you think that you can’t?
@@PairingWithDuncan The examples that are demonstrated are on JVM and JUnit
@@skarloti yes, but I believe that Power Assert will work fine with Kotlin.test tests on other platforms