-
Notifications
You must be signed in to change notification settings - Fork 45
[WIP] "Orchestrator like" execution mode #138
[WIP] "Orchestrator like" execution mode #138
Conversation
.value() | ||
|
||
fun parseTests(testApkPath: String) = DexParser.findTestMethods(testApkPath) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please specify return type explicitly here?
@@ -3,6 +3,9 @@ package com.gojuno.composer | |||
import com.gojuno.commander.android.aapt | |||
import com.gojuno.commander.os.Notification | |||
import com.gojuno.commander.os.process | |||
import com.linkedin.dex.parser.DexParser | |||
import com.linkedin.dex.parser.TestMethod |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks unused :)
@dsvoronin PTAL |
fun parseTests(testApkPath: String) : List<TestMethod> = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can add an integration test (we already have some that parse runner from test apk, you can add couple tests there)
Not that I don't trust this library, but it can help catch future regressions!
@artem-zinnatullin
|
.value() | ||
|
||
fun parseTests(testApkPath: String) : List<String> = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like we need to keep TestMethod, to filter out @Ignore
before run and keep custom annotations info
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we'd have own TestMethod objects (we have some, I'm not sure they cover this use-case), so plugins (see below) could extend it with custom info and Dexparser lib would be just implementation detail rather than API everyone has to use
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, i'm all into this kind of abstraction
.value() | ||
|
||
fun parseTests(testApkPath: String) : List<String> = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, we need handling of our own annotations to modify resulting junit report. How this can be possible without forking composer? Any plugin mechanism?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
answering my own question: probably we need something like this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we discussed plugins before, it shouldn't be super hard since we're running Composer on JVM. We can add a parameter to load plugin(s) as jars and can add abstractions and APIs to hook into
@dsvoronin can you please create a separate issue for Plugin System?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not Artem :) , but we need at least We definitely need abstraction for different strategies here |
I'd start with just integrating Orchestrator-like process isolation into current shart true/false mode Dynamic test sharding is just something we can build on top of test parsing, we should allow running dynamically sharded tests without "Orchestrator" right |
+1 for polling from the main queue and having in mind other strategies in future. |
@@ -198,6 +198,11 @@ private fun List<String>.pairArguments(): List<Pair<String, String>> = | |||
} | |||
} | |||
|
|||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: remove extra line above/below function
@@ -18,5 +18,8 @@ class ApkSpec : Spek({ | |||
it("parses test package correctly") { | |||
assertThat(parseTestPackage(testApkPath)).isEqualTo(TestPackage.Valid("test.test.myapplication.test")) | |||
} | |||
it("parses tests list correctly") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: extra line?
LGTM, let's merge as first part? |
@artem-zinnatullin yup, the only question is unchecked "Execute list of tests", @tagantroy are you going to add smth here? |
@artem-zinnatullin @yunikkk let's merge it |
@tagantroy merged |
#135 implementation