feat(test): cowtowncoder#87 Add tests to jug #113
Conversation
- This should make it a bit easier to test
- Placed this in a parameterized test suite to allow for a wide range of assertions
| public static void main(String[] args) | ||
| { | ||
| new Jug().run(args); | ||
| } | ||
|
|
||
| public void run(String[] args) { |
There was a problem hiding this comment.
This is effectively the core of this change on this file, I destaticised most of the methods, the only one that is still static is main.
Take note that I have tried my best to not touch too much of the main file, just shuffling the methods around so it is easier to test.
Also take note that Intellij appears to have applied its own automated styling guidelines, so I would like to apologise in advance for the changes.
SquireOfSoftware
force-pushed
the
add_tests_to_jug
branch
from
5b8d62e
to
078bb6a
Compare
| new UseCase("n", "-n", "world", "-s", "url"), | ||
| new UseCase("n", "-n", "world", "-s", "dns") |
There was a problem hiding this comment.
Here is some of the parameterized tests that I have applied, it looks kinda like this:
| } | ||
|
|
||
| @Test | ||
| public void run_givenNoOptions_shouldProduceUUID() { |
There was a problem hiding this comment.
Each subtest is testing an option on that UUID type.
| // then - if it is a UUID then we should be able to parse it back out | ||
| String actualUuid = outContent.toString(); | ||
| assertEquals('\n', actualUuid.charAt(actualUuid.length() - 1)); | ||
|
|
||
| assertEquals(UUID.class, | ||
| UUID.fromString(actualUuid.substring(0, actualUuid.length() - 1)).getClass()); |
There was a problem hiding this comment.
I wasn't super sure how I was going to validate a UUID version, without digging into the actual spec expectation...like what does the first 6 bits mean etc.
But I figured, I would just hook myself into the output stream and as long as I can feed the UUID back into the UUID class then it means its a UUID of some kind...but I am unsure if that makes sense because you actually want to know if the UUID spec is met right? Rather than just checking to see if its UUID-parseable.
There was a problem hiding this comment.
I don't think we need to thoroughly test validity at this level: these aspects are verified by other, existing unit tests. So "looks about right" is pretty good at CLI level I think. Use of JDK UUID constructor makes sense to me.
What did I do?
As per this comment: #87 (comment), I wrote some tests for Jug.
I took the liberty to "destaticise" the main static methods so that it was easier to target inside of the tests. Take note that some of the styling changes were automatically applied by Intellij so I apologise in advance for that, if it needs to be rolled back let me know.
The general gist of the work is, run through the
runmethod, swap out the System.out and System.err outputStreams using: https://stackoverflow.com/questions/1119385/junit-test-for-system-out-printlnExtra notes
Let me know if the coverage is not good enough and I can add more usecases to the tests, these tests are just covering the "happy path". Also I did not test every permutation of options.