Writing parameterized test cases enables developers to improve code robustness without writing multiple flavors of the same test or burying the majority of testing logic in helper methods away from the test itself. Succinctly put, test parameters provide more coverage with less code. Recently, I found myself in need of
My two oldest kids love Star Wars. Recently, their grandparents showed them a Lightsaber app where you can choose a saber and wave the phone around to simulate a battle, complete with all the beloved sound effects. Inspired by the kid's enjoyment, I decided to take the opportunity
I use the Kotlin Playground throughout my workday to provide more thoughtful code reviews with compilable suggestions, check my understanding of a Kotlin language feature or API, or test out an idea I may have for an implementation without needing to operate within the confines of a less iterative environment
I have never used Workflow before working at Square, and while the programming paradigm requires a slight learning curve for first-time users, the framework does elegantly deliver on the promise of enabling a developer to drive an application with composable state machines. However, this writing is not an evaluation of
A well-designed API provides interfaces that are difficult to misuse. In general, the Kotlin APIs are delightful, but I recently debugged a crash with a stack trace that contained something similar to the following. java.lang.IllegalStateException: Function0<java.lang.String> at SomeClass.andFunction(...)(SomeClass.kt) ... The stack