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

Compile and overwrite test #175

Merged
merged 16 commits into from
Oct 15, 2021
Merged

Compile and overwrite test #175

merged 16 commits into from
Oct 15, 2021

Conversation

judovana
Copy link
Owner

@judovana judovana commented Oct 7, 2021

No description provided.

Where SourceTestClassWrapper is abstract, and do all ahrd work. The
TestingDummyHelper jsut sets pkg, classname and class body
CliTest.java and CompileUploadCliTest are now extending
AbstractAgentNeedingTest.java and so shoudl have no shared duplicated
code.

CompileUploadCliTest is now partially similar to CliTest, but is using
ModifiableDummyTestingHelper instead of TestingDummyHelper
@AurumTheEnd AurumTheEnd changed the title Comile and overwrite test Compile and overwrite test Oct 7, 2021
Oh it did usefull thinhg! It removed all nasty static imports!
@AurumTheEnd
Copy link
Collaborator

AurumTheEnd commented Oct 8, 2021

I would suggest moving the "utility" classes to a different package in order to differentiate them from the actual org.jrd.backend.data test classes (CliTest, CompileUploadCliTest, but also ArchiveManagerOptionsTest). Thoughts?

@judovana
Copy link
Owner Author

judovana commented Oct 8, 2021 via email

@AurumTheEnd
Copy link
Collaborator

AurumTheEnd commented Oct 8, 2021

Tests will fail until #111 is implemented. CompileUploadCliTest is currently essentially dependent on what plugins the user set up with the GUI, which is definitely unwanted testing behavior.

EDIT: it is too late for me to understand why the CI test passed. No idea. Dumbfounded. Perplexed. Astonished. Too many emotions.

EDIT EDIT: Oh yeah, in Model, we are creating PluginManager, which on fresh installs imports all the plugins because of ee08f01. But because I don't have a fresh install, but am also missing some plugins because I don't use them, their tests fail locally. Very interesting and unintuitive behavior.

@AurumTheEnd
Copy link
Collaborator

The Windows test has been running for 10 minutes, that isn't good. Mainly because I will have to be the one fixing it.

@judovana
Copy link
Owner Author

judovana commented Oct 8, 2021

Tests will fail until #111 is implemented. CompileUploadCliTest is currently essentially dependent on what plugins the user set up with the GUI, which is definitely unwanted testing behavior.

Right you are. I will add some assume.
Btw, do you mind to check my usage of streams.get.... ?
In the api test, the output of compilation is never here.

EDIT: it is too late for me to understand why the CI test passed. No idea. Dumbfounded. Perplexed. Astonished. Too many emotions.

yah:(
I'm inclining to the bad unloading of agent.

EDIT EDIT: Oh yeah, in Model, we are creating PluginManager, which on fresh installs imports all the plugins because of ee08f01. But because I don't have a fresh install, but am also missing some plugins because I don't use them, their tests fail locally. Very interesting and unintuitive behavior.

Very interesting!

That was also my impression, that the plugin manager shoudl work with fresh install. And I have correct setup :)

@AurumTheEnd
Copy link
Collaborator

Btw, do you mind to check my usage of streams.get.... ?

I have not done a in-depth review yet. When I do in the next few days, I'll comment on it. Please don't merge this PR until then :D


EDIT: it is too late for me to understand why the CI test passed.

I'm inclining to the bad unloading of agent.

I was talking about the CompileAndUpload tests regarding different plugins. The passing overwrite test is a separate mystery.

…cli and args

For Prokop: fields - class instance variales - are here to keep state of the
object.
Local variables, are here to see state of method. All this allows you
better separation of member methods, utility methods and future
exnesions without massive refactoings
@@ -76,4 +76,4 @@ jobs:
- name: Test Cli
run: |
cd jrd
mvn --batch-mode test -Dtest=CliTest -DfailIfNoTests=false
mvn --batch-mode test -Dtest=*CliTest -DfailIfNoTests=false
Copy link
Owner Author

Choose a reason for hiding this comment

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

Why there is this condition at all? Test all!
Also the -DfailIfNoTests=false seems wrong. lets fail

Copy link
Owner Author

Choose a reason for hiding this comment

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

ook. thanx

@AurumTheEnd
Copy link
Collaborator

I see your 20 minute timeout still didn't help on Windows. Since all tests finish in under a minute on Ubuntu, this is a more serious issue than Windows just being slightly slower (which was the case prior to this PR - Windows build took about 1.5x the total time of the Ubuntu one).

@judovana judovana force-pushed the comileAndOverwriteTest branch from 7e3e241 to fdbdcf5 Compare October 10, 2021 08:00
@judovana
Copy link
Owner Author

I see your 20 minute timeout still didn't help on Windows. Since all tests finish in under a minute on Ubuntu, this is a more serious issue than Windows just being slightly slower (which was the case prior to this PR - Windows build took about 1.5x the total time of the Ubuntu one).

yy. remopved

Comment on lines 53 to 118
void testBytes() throws Exception {
testBytes(dummy.getPid());
testBytes(dummy.getClasspath());
}

void testBase64Bytes(String pucComponent) throws Exception {
args = new String[]{BASE64, pucComponent, dummy.getClassRegex()};
cli = new Cli(args, model);

cli.consumeCli();

byte[] base64Bytes = streams.getOut().trim().getBytes(StandardCharsets.UTF_8);
byte[] fileContents = Files.readAllBytes(Path.of(dummy.getDotClassPath()));
byte[] encoded = Base64.getEncoder().encode(fileContents);

assertArrayEquals(encoded, base64Bytes);
}

@Test
void testBase64Bytes() throws Exception {
testBase64Bytes(dummy.getPid());
testBase64Bytes(dummy.getClasspath());
}

void testBytesAndBase64BytesEqual(String pucComponent) throws Exception {
args = new String[]{BYTES, pucComponent, dummy.getClassRegex()};
cli = new Cli(args, model);

cli.consumeCli();
byte[] bytes = streams.getOutBytes();

args = new String[]{BASE64, pucComponent, dummy.getClassRegex()};
cli = new Cli(args, model);

cli.consumeCli();
String base64 = streams.getOut().trim();
byte[] decoded = Base64.getDecoder().decode(base64);

assertArrayEquals(bytes, decoded);
}

@Test
void testBytesAndBase64BytesEqual() throws Exception {
testBytesAndBase64BytesEqual(dummy.getPid());
testBytesAndBase64BytesEqual(dummy.getClasspath());
}


void testDecompileJavap(String pucComponent, String option) throws Exception {
args = new String[]{DECOMPILE, pucComponent, "javap" + option, dummy.getClassRegex()};
cli = new Cli(args, model);

cli.consumeCli();
String jrdDisassembled = streams.getOut();
String javapDisassembled = dummy.executeJavaP(option);

// JRD javap has additional debug comment lines + header is different
assertEqualsWithTolerance(jrdDisassembled, javapDisassembled, 0.8);
}

@ParameterizedTest
@ValueSource(strings = {"", "-v"})
void testDecompileJavap(String option) throws Exception {
testDecompileJavap(dummy.getPid(), option);
testDecompileJavap(dummy.getClasspath(), option);
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

There should be and explanatory comment of why these tests are duplicated from the normal CliTest here: They support the later tests where bytes and javap functionality is needed, but not the tested subject.

@@ -144,14 +144,15 @@ private static int min3(int a, int b, int c) {
}
}

public static class StreamWrappers {

public static class JunitStderrOutThief {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I do not understand this renaming.

Comment on lines +564 to +566
* Although the class definition was transforemd, in OpenJDK HotSpot
* this implementation of dummy do not request the new definition,
* adn continues to spit out its jitted output
Copy link
Collaborator

Choose a reason for hiding this comment

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

Interesting. So it's basically the exact opposite of what we originally expected to happen: source code changes (which we expected not to withstand multiple cli calls), but output doesn't change (which we expected to change).

}
}

public static String readBinaryAsString(FileInputStream input, String charBase, CodingErrorAction action) throws IOException {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Unused parameter action.

@@ -262,13 +268,28 @@ private void overwrite() throws Exception {
}
}

@SuppressFBWarnings(value = "OS_OPEN_STREAM", justification = "The stream is clsoed as conditionally as is created")
Copy link
Collaborator

Choose a reason for hiding this comment

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

Probably could be cheesed by having the condition as a final boolean variable. Probably.

@judovana
Copy link
Owner Author

judovana commented Oct 14, 2021

I see your 20 minute timeout still didn't help on Windows. Since all tests finish in under a minute on Ubuntu, this is a more serious issue than Windows just being slightly slower (which was the case prior to this PR - Windows build took about 1.5x the total time of the Ubuntu one).

yy. remopved

see #182

Please fix in a separate PR.

@AurumTheEnd AurumTheEnd force-pushed the comileAndOverwriteTest branch 2 times, most recently from bc5fcdb to 5d6e13e Compare October 14, 2021 20:32
@AurumTheEnd AurumTheEnd force-pushed the comileAndOverwriteTest branch from 5d6e13e to ff36371 Compare October 14, 2021 20:35
@AurumTheEnd
Copy link
Collaborator

Please fix in a separate PR.

Nah. :)

@AurumTheEnd AurumTheEnd force-pushed the comileAndOverwriteTest branch 2 times, most recently from 60ded2b to 0500b20 Compare October 14, 2021 21:18
@judovana
Copy link
Owner Author

judovana commented Oct 15, 2021 via email

@AurumTheEnd AurumTheEnd force-pushed the comileAndOverwriteTest branch from 0500b20 to 17459ed Compare October 15, 2021 09:18
… issues

Which is my only guess for why "javap -v" was stuck on loop forever.
Stdout & stderr are now read in a loop rather than at once, and also their reading occurs at least once before the process is waitedFor().
The switch has to be in quotes, because Powershell, the default runner on windows-latest, interprets the dot in the property name as... some sort of keyword.
Instead of using some word-boundary using regex to match the plugin, we can skip the whole CLI and temp file ordeal by using the plugin manager.
@AurumTheEnd AurumTheEnd force-pushed the comileAndOverwriteTest branch from 17459ed to 036a98b Compare October 15, 2021 09:23
@AurumTheEnd AurumTheEnd linked an issue Oct 15, 2021 that may be closed by this pull request
@AurumTheEnd AurumTheEnd merged commit ea133d5 into master Oct 15, 2021
@judovana judovana deleted the comileAndOverwriteTest branch February 22, 2024 11:14
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.

javap exec is missuning shared stderr/out
2 participants