Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parameterized classes are incorrectly included into test targets that filter them out #1242

Closed
valeraz opened this issue Oct 15, 2020 · 2 comments
Assignees
Labels

Comments

@valeraz
Copy link
Contributor

valeraz commented Oct 15, 2020

Describe the bug

A clear and concise description of what the bug is.

Test classes annotated with @RunWith(Parameterized::class) end up running as part of flank invocations that do not include these classes in the config.

To Reproduce

Steps to reproduce the behavior:

  1. Create an parameterized instrumentation test class in package foo.bar. For example:
package foo.bar 

@RunWith(Parameterized::class)
class FooTest(private val horizontal: Boolean) {

  @Test
     test_one() {
       assert(true)
  }

    private companion object {
    @JvmStatic
    @Parameterized.Parameters
    fun data(): Collection<Boolean> = listOf(
      true,
      false
    )
  }
}
  1. configure flank to run tests in a different package. For example:
test_targets:
- package foo.baz

Expected behavior

A clear and concise description of what you expected to happen.

parameterized class from step 1 should not be executed as part of the flank run

Actual: see see something like this:
80 tests + 1 parameterized class / 81 shards (where the parameterized class is outside of the configured target)

Details (please complete the following information):

Have you tested on the latest Flank snapshot? No

Post the output of flank --version.
version: v20.09.3

Additional context

Add any other context about the problem here.

@valeraz valeraz added the Bug label Oct 15, 2020
@pawelpasterz pawelpasterz self-assigned this Oct 16, 2020
@pawelpasterz
Copy link
Contributor

I think this is the same issue as #1234, fixed in #1233
I was unable to reproduce this error with the current master git checkout d7b74e but this error occurred without #1233 fix (git checkout f34ee09 commit before fix)

@valeraz if it's not a problem, let me know if you receive the same error with a snapshot version

@pawelpasterz
Copy link
Contributor

Closing due to the impossibility of reproducing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants