Since Google declared Kotlin as the official language for Android, Kotlin has become one of the fastest growing languages in the coding world and current projections forecast continued increased global use. One year ago, I started using Kotlin to help me solve everyday problems in the office. Then I wrote a programmatic wizard for sales people to generate live demos for prospective clients because, well, I’m lazy.
I ended up writing my own drag-and-drop functionality because I didn’t know how to serialize my custom objects; the problem was that I was having a tough time debugging my micromanaged events, and I realized I needed testing for the UI. The other problem? I had no idea how to write UI tests. I thought— what if I used metaprogramming to generate these tests for me?
So I set out to ask other developers and QA engineers:
- What makes a good test?
- What makes a bad test?
TornadoFX-Suite started out with simply generating TornadoFX UI tests. But there’s more to it than that. If this project can be used by multiple people for multiple frameworks — could we collect that data and use machine learning to find these answers? The natural progression from metaprogramming is machine learning. Kotlin is not quite ready to call itself a data stack yet, but it has already started addressing the necessary components for a robust and stable software needed handle & analyze large data systems.
This talk is an exploration in the philosophy of what makes an application, how we can formalize that philosophy in an abstraction of contract and property-based testing, and how we can use Tensorflow to help us find suggestive data points between the effectiveness of the tests we write and the circumstances surrounding the project being tested.