Test class survived while renaming the package/moving it to another package

Old Forum
1

After renaming a package we ended up in failing test cases because the old test class survived and tried to make use of a production code class which was also moved to a new package (ClassNotFoundException).

The changeset was pretty big but all tasks prior to test were successful.

we are using gradle 2.2.1.

1 Like
2

The ‘JavaCompile’ task will recompile any new or changed classes however it does not go so far as to remove deleted or renamed classes from its output directory. In this case, you would have to clean your test code output directory.

$ gradlew cleanCompileTestJava

3

Yes, I’ve seen broken tests a few times because of this. I think it really should be fixed. A really common usage case is to run a build, and then ‘git checkout’ a different branch. If the test code does not exist in the other branch you end up getting test failures. For a normal Java compile its not really an issue since the “orphaned” class files do not impact the valid classes. Not true for tests.

Running clean isn’t really an option because it defeats the incremental build feature which is needed for any moderately sized project. Also most normal users (i.e. developers) aren’t going to figure this error out until they’ve hit a few times.

4

Stale class files do get cleaned. The only (known) case where this doesn’t happen is if all of a source set’s sources are removed. In that case, the compile task won’t run at all, and therefore won’t get a chance to clean stale files. This is a known limitation which will definitely get fixed at some point.

5

It looks like that was the exact circumstance in which I tested this, which explains the results I saw. You are correct, deleting a class did seem to remove it from its output directory so long as there was other existing source.

Could there be any explanation for the behavior the others are seeing?

6

Casey’s case sounds like the empty source set case (new branch has no tests). My best guess is that this also holds for the OP (classes moved to new package in different source set).

7

We moved classes to a new package in the same source set. Furthermore, compile tasks were running. Sadly, I was not able to reproduce this one locally (it happened in CI).

8

As epee, we have also faced this issue on our CI builds: Moved one class from package x.y.z to x.y.w (same project, same sourceset) we saw the two .class files in the build/classes directory. I wasn’t able to reproduce this locally (server runs with --no-daemon, gradle 2.2.1)

We are now using this as a trade-off between working incremental and full clean builds:

[compileJava,compileTestJava].each { task ->

task.doFirst {

delete task.destinationDir

} }