Skip to content

Remove legacy tests #3962

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

Merged
merged 9 commits into from
Feb 12, 2018
Merged

Conversation

OlivierBlanvillain
Copy link
Contributor

This PR removes the legacy tests infrastructure and adds a simple meta test to check the output of Vulpix. I don't think it makes sense to test all features of Vulpix using this style given that the output of sbt is quite unreliable (timing annotations and out of order execution).

This new test checks that the framework rejects incorrect pos/neg and
run test. I think addition meta tests should rather be added as part of
the unit test infrastructure, given than this is rather heavy to maintain.
(Note that sbt-output.check is manually annotated with "SKIP" lines)
* These are legacy, do not add tests here, see `CompilationTests.scala`
*/
@Category(Array(classOf[LegacyTests]))
class tests extends CompilerTest {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe you can now remove CompilerTest


echo "running Vulpix meta test"
tmp=$(mktemp)
if sbt "dotty-compiler/testOnly dotty.tools.vulpix.VulpixMetaTests" > "$tmp" 2>&1; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sbt -no-colors

@smarter
Copy link
Member

smarter commented Feb 5, 2018

I don't think it makes sense to test all features of Vulpix using this style given that the output of sbt is quite unreliable (timing annotations and out of order execution).

But we could just run vulpix outside of sbt after compiling it to avoid this problem.

@OlivierBlanvillain
Copy link
Contributor Author

OlivierBlanvillain commented Feb 5, 2018

@smarter Still, these end-to-end tests require manual annotation of the text output of vulpix (see the lines annotated with SKIP at EOL in this file). It's just more convenient to write a regular unit test, for instance this commit 8e0f219 took around 5 minutes to write, I don't see what's to be gained by turning that into an end-to-end test.

If we know that a failing run test throws an exception that makes the CI fail (the meta test), and that a timing out run test throw an exception, then it should be safe to deduce that a timing out run test makes the CI fail.

Before that sbt ran without the -Dsbt.ivy.home option set and
the dependencies where downloaded again...
@Test def runTimeout: Unit = {
try {
compileFile("tests/vulpix-tests/unit/timeout.scala", defaultOptions).checkRuns()
assert(false, "unreachable")
Copy link
Contributor

@allanrenucci allanrenucci Feb 12, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fail("unreachable")

compileFile("tests/vulpix-tests/unit/deadlock.scala", defaultOptions).expectFailure.checkRuns()

@Test def badJava: Unit =
try compileFile("tests/vulpix-tests/unit/BadJava.java", defaultOptions).suppressAllOutput.checkCompile()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

try {
  ....
  fail("unreachable")
}

@Test def badJava: Unit =
try compileFile("tests/vulpix-tests/unit/BadJava.java", defaultOptions).suppressAllOutput.checkCompile()
catch {
case ae: AssertionError => assert(ae.getMessage.contains("java compilation failed"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assertTrue

assert(false, "unreachable")
} catch {
case ae: AssertionError =>
assert(ae.getMessage == "Run test failed, but should not, reasons:\n - test 'tests/vulpix-tests/unit/timeout.scala' timed out")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assertEquals(ae.getMessage, ...)

fi
tmp1=$(mktemp)
cat "$tmp" | sed '/Test run started/,$!d' > "$tmp1"
while read expected <&4 && read actual <&3; do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I would remove the -x option of the script. Otherwise the code below prints a lof of noise

}
catch {
case _: IllegalArgumentException => // pass!
case NonFatal(_) => fail("wrong exception thrown")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would remove this line

fail("didn't fail properly")
}
catch {
throw new Exception("didn't fail properly")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe, factor this into a method fail() with a comment saying that JUnit Assert.fail cannot be used because it throws an AssertionError and that's what we expect to catch.

@OlivierBlanvillain OlivierBlanvillain merged commit 23c6cef into scala:master Feb 12, 2018
@allanrenucci allanrenucci deleted the no-legacy-no-more branch February 12, 2018 14:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants