yeah the tests need all of them, adding (unnecessary) code to satisfy a test is not a good thing

I am rewrting the last big java part from keepass to kotlin

the

KeepassRepository

class

I did a simple test with the “refactor java to kotlin” but that was not a real success ™️

I find these constructs

val entries : MutableList<Entry>?
        get() = keepassFile?.entries

so elegant

Yeah it's great 🙂 I use that one a lot as well.

I am a tiny bit miffed with myself, keepassRepository does not have enough tests

I wanted a nice way to activate the textfield when it becomes visible, so I added a

whenVisible

function and used it like this:

whenVisible { requestFocus() }

@User uploaded a file:

changed the colors of the coverage to pop a bit more 🙂

Looks good. Kotlin is beautiful :)

it is but I get a false positive from the coverage tool:

@User uploaded a file:

the kotlin file KeepassRepoKt contains the class KeepassRepo

Please don't run any of that against TornadoFX 😁

you dont want tornadoFX well tested?

on a serious note, I have not found a decent way to test javafx code that does not involve adding all those id's

I try to have all the business logic seperated from the tornadoFX code and have good tests for that

Ids are good way to go, because you can change the hierarchy without breaking the test.

Another possibility is assigning variables in the View, but you know I get cranky when you do 😁

you are not the only one who gets cranky I dont like it either and I am always searching for ways not have them

I changed to a more event based approach in the Todo app. Not because I think it's really warranted in such an app, but it decouple the app a little.

I never create them anymore, ever.

This is the store in the todo app with all the business logic:

@User uploaded a file: Untitled

I'm on the fence about using events or functions.

This is the same controller with functions:

@User uploaded a file: Untitled

I think I might go back to functions.