charmplusplus / projections

Performance Analysis Tool for Charm++
Apache License 2.0
5 stars 3 forks source link

add make test #77

Closed matthiasdiener closed 4 years ago

matthiasdiener commented 5 years ago

Currently fails on Travis with:

$ make test
gradle copyJarToBin
:compileJava UP-TO-DATE
:processResources NO-SOURCE
:classes UP-TO-DATE
:fatJar
:copyJarToBin
BUILD SUCCESSFUL in 6s
3 actionable tasks: 2 executed, 1 up-to-date
bin/projections --exit test/hello.sts
Exception in thread "main" java.awt.HeadlessException: 
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
    at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:204)
    at java.awt.Window.<init>(Window.java:536)
    at java.awt.Frame.<init>(Frame.java:420)
    at java.awt.Frame.<init>(Frame.java:385)
    at javax.swing.JFrame.<init>(JFrame.java:189)
    at projections.gui.MainWindow.<init>(MainWindow.java:103)
    at projections.analysis.ProjMain.startup(ProjMain.java:166)
    at projections.analysis.ProjMain.main(ProjMain.java:181)
make: *** [test] Error 1
matthiasdiener commented 5 years ago

Better, but still fails with

bin/projections --exit test/hello.sts
Found 4 log files
Found 4 sum files
java.lang.NullPointerException
    at projections.analysis.LogLoader.determineEndTime(LogLoader.java:103)
    at projections.analysis.Analysis.findEndTime(Analysis.java:257)
    at projections.analysis.Analysis.initAnalysis(Analysis.java:182)
    at projections.analysis.ProjMain.startup(ProjMain.java:171)
    at projections.analysis.ProjMain.main(ProjMain.java:194)
make: *** [test] Error 1

, since determineEndTime() depends on a GUI object (which we can't have with Travis).

matthiasdiener commented 5 years ago

Agreed. In any case, we need a way to run projections in a headless way, which can be used in gradle check on Travis.

matthiasdiener commented 4 years ago

I think this should be using gradle check (which runs by default in Travis) instead. I need to look up exactly how to do so, but I think it'll involve just exposing a method (or a few) that will be executed as tests. Doing so will be more semantically useful than just using make test like this.

Adding support for gradle test/check will require quite a bit more effort: https://www.tutorialspoint.com/gradle/gradle_testing.htm

Imho, we could merge this patch and work on a more comprehensive testing suite afterwards.