I’ve only begun reading the book, and like what I see. Doing the first Test portion around addition, and wondering if you’ve ever examined Kotest? A Kotlin specific testing framework.
It has been around awhile, and has excellent support, active devs, and a plugin for IntelliJ.
I like it because it leverages Kotlin throughout, has different testing styles to suit your requirements, and preferences, an excellent assertion library (that can be used in isolation), and solid property-based testing, including shrinking.
I really like its assertion style of
(x + y) shouldBe 12, and similar. It has a solid selection of assertions. Very close to AssertJ, and the community/developers are quick to respond to inquiries.
I thought I’d pass it along in case you’d never seen it. Well worth investigating IMO.
Looking forward to the rest of the book.
Thanks, I know it but personally I prefer Strikt syntax. It’s mostly a matter of taste, maybe I should mention Kotest as an alternative…
Agreed that a lot comes down to personal preference. I did a fair bit with Groovy, and Spock assertions, and really liked the lack of keywords. Kotest assertions comes closest to that for me, hence my.preference for it.
Yes I loved Spock as well and I can understand you. Still when I need assertions on collections etc I like to have good IDE suggestions, hence Strikt.
I’ve always found Idea does a very good job of figuring out the right suggestions, and keeps getting better all the time.
But definitely use what makes you happiest, and most productive. There’s no shortage of tools to choose from in our industry. All of them with objective pros/cons, and subjective pros/cons.
Really enjoying the design ideas I’m gaining from the book. Also having ‘fun’ with Kotlin, as unfortunately, I don’t get to use it in my day job anymore
Working through the early days of the book ‘forced’ me to dig into the inner workings, and code samples. Nothing like digging in to truly learn, and understand the design, and process.
But constructive feedback. Hopefully the technical reviewers will get the examples, and sample code, better working than it was in the early days, or else it will cause a number of people to give up way too early.
I see the source code as a zip. I searched, but didn’t find a repo on Github. Is there a publicly available repo with the source code? I ask as it makes determining what has changed so much easier, and I like to see the evolution. Completely understand if you don’t want to share it, though.
Thanks again, and keep up the good work. I really appreciate it when people take the time to share their ideas.
Personally, I don’t have any problem is releasing the full git repo once the book is finished. I’m not sure if PragProg is ok… probably yes but I have to check.
I know that some people are taken aback from the source code… I’ve tried as much as possible to clarify in the text the steps but I think that to understand properly you need to look at the code.
I don’t really know a perfect solution, because I don’t want to reduce “the scope” of the book to make it simpler, since there are already many great books for beginners.
I hope someone will still find it interesting.
Btw there is a huge request of Kotlin backend devs in London and Europe in general… just saying
I’ll keep my eyes open for a Git repo. Until then, I download the zip periodically, do a directory comparison, and have it in a local Git repo.
For the source code, I wasn’t suggesting changing the scope. I agree that reducing scope, would also reduce the value of the book. It’s aimed at an advanced audience, so it falls on the reader to do some work.
My reference was more to some of the existing issues, or inconsistencies, of the textbook code vs the source code, and having to struggle with that sometimes. I’m ok with that, and somewhat expect it, given I’m working with a pre-release version. Definitely something the technical reviewers will hopefully tidy up.
I’m definitely enjoying the book, and recommend it to people that want to see a real application of Functional practices, as well as a very solid way to architect code so that it can be easily tested with, and w/o, communication protocols in place. I really like how the approach forces a separation between business logic, and external API interactions.
I hope to remove them all before final version. For sure I’m happy to keep errata of whatever we missed.