Migrate unit tests to a Kotlin testing framework about ktx HOT 9 CLOSED

Thanks, that's great. It's possible to merge 2 repositories keeping the commits history, I can do that on a separate branch. You'll appear as a contributor and all of your commits will be there.

Can't promise anything, but I'll try to look into it this week. I'll create a separate issue for that.

from ktx.

After a quick look, I think you're overusing field delegation and Box2D class wrappers.

For example, you can add body method as an extension of World:

fun World.body(init: (@Box2dDsl FixtureDef).() -> Unit) {
}

This wouldn't force the users to wrap and unwrap Box2D classes with your DSL objects.

You overuse delegation mechanism:

    var type: BodyDef.BodyType by object {
        operator fun getValue(bodyDefDsl: BodyDefDsl, property: KProperty<*>): BodyDef.BodyType = bodyDef.type
        operator fun setValue(bodyDefDsl: BodyDefDsl, property: KProperty<*>, type: BodyDef.BodyType) {
            bodyDef.type = type
        }
}

// Equivalent to:
    var type: BodyDef.BodyType
        get() = bodyDef.type
        set(value) { 
            bodyDef.type = value
        }

If you browse through the current ktx-style module sources, you can see that type-safe builders with @DslMarker can be successfully used on classes that aren't yours. I think this approach is generally more convenient for the library users.

from ktx.

Tests written in KotlinTest cannot be run individually. You can run individual test suite, not but an individual test. It's not that tedious, since most KTX tests take milliseconds to run, but it's certainly a step backwards from JUnit. I think using JUnit with Kotlin backticks to name test methods, Mockito-Kotlin for mocks and KotlinTest assertions is optimal for now.

from ktx.

Did you consider using Spek? It's more idiomatic to Kotlin than JUnit, and with the spek-idea-plugin you are able to run each test individually.

from ktx.

I've seen this framework a while back and dismissed it for some reason. I think it required a lot of extra setup and JUnit 5 usage. I'll look into it again, thanks.

Anyway, Box2D utilities is something I was planning on eventually adding to KTX - and I really don't like reinventing the wheel. Would you consider merging your gdx-box2d-kotlin repository with KTX as an additional ktx-box2d module? I'd have to review the code first and might end up refactoring some stuff, but the README example is promising and looks pretty much like idiomatic Kotlin builder API.

from ktx.

Sure, I'd be more than happy to contribute gdx-box2d-kotlin - I could prepare a PR and let you review and refactor the code that way? (or if you just want to dive in and grab what you want, I'm ok with that too)

from ktx.

#52

from ktx.

Nice suggestions - I'll probably make those changes if I have time this week.

from ktx.

We've included Mockito 2 with Kotlin utilities and KotlinTest (mostly used for its assertions). I've improved readability of tests in most modules: replaced camelCaseMethodNames with human-readable Kotlin backticks method names, removed unnecessary assertions, visually separated preparation, invocation and testing phases (given, when, then) and removed some unnecessary comments. I'm satisfied with the current state of KTX tests, so I'm closing this issue.

Anyway, I haven't touched ktx-vis, but its tests are mostly fine. @kotcrab - you can look into that if you've got some spare time, but it's not a priority. ;)

from ktx.