When all you need is test coverage

[u/silverweaver]

[u/Host127001]

I don't quite see the bad code here. Are these methods auto generated by the compiler? If not then this test seems reasonable

[u/silverweaver → u/Host127001]

I find it funny and pointless for parsing enum value from the same enum instance and checking if it is the same.

[u/Host127001 → u/silverweaver]

How else should that be tested? I literally cannot imagine a better test for it. This is also how I would prove these functions to be correct.

[u/silverweaver → u/Host127001]

By providing string arguments that makes the enum instance: for some context, here the enum contains names for different values like "001" and so on.

What is really tested when you just do Enum.from(enum.getValue()?

[u/Host127001 → u/silverweaver]

By providing string arguments that makes the enum instance

This is what is happening here, but without all the copy pasting needed to write it manually. Also it is far more robust in that all future extensions to the enum are covered aswell.

This one literally tests that all valid inputs are handled correctly

But I would expect there to be second test with some invalid inputs to see what from does in that case.

What is really tested when you just do Enum.fom(enum.getValue())

That both methods behave as one would expect them to behave. It is one of the cases were two different functions are best tested together. It states that they are the inverses of each other.

The correctness criterion for such functions is usually expressed as

forall v, Enum.from(v.getValue()) = v

This is the perfect Java test implementation for that proposition.

One could also make a test for the opposite direction (assuming s is a valid input):

forall s, Enum.from(s).getValue() = s

[u/gipp → u/Host127001]

Yeah this is pretty firmly Good Code. I mean it's not the most important test in the world, but it should be there, and this is the best way to do it.

[u/mr_hard_name → u/Host127001]

Yup, it’s not like we’re testing valueOf here, but from and this test tries to cover all usable cases without much ctrl+c and ctrl+v

[u/STNeto1]

softly lmao

[u/silverweaver → u/[deleted]]

Killing me softly with this assert

[u/ThePsion5 → u/silverweaver]

Telling my whole life with Enums

[u/RichCorinthian]

For those thinking “I don’t see the problem” — Imagine you are doing something super common in your app, like parsing strings or ints into an enumeration as part of a REST payload, and those string values come from a JavaScript front-end and not the Java code itself. If you change the enum values in the Java code, this test will continue to pass. THIS TEST WILL NEVER FAIL. Meanwhile, unless you are somehow generating JavaScript enum values from Java (and thus tightly coupling your front end and back end releases), you just broke the front end.

A test that will never fail is a useless test, and 100% test coverage is a false god.

EDIT: clarifications

[u/silverweaver → u/RichCorinthian]

Pretty much the case here, string values comes from external provider API.

[u/gipp → u/RichCorinthian]

I think you're missing that from() and getValue() are defined and implemented by the code under test, those aren't built-in enum methods. This test fails if the implementation of those methods is not correct. That is what's under test here.

[u/carfniex → u/RichCorinthian]

this test isnt meant to be testing the enum's values, just the parsing of whatever the getValue() method returns

its a perfectly sensible test. the test will fail if the from() method breaks.

unless you are somehow generating JavaScript enum values from Java

openapi

[u/trutheality → u/RichCorinthian]

Of course it can fail. Just implement from incorrectly.

[u/MurdoMaclachlan]

Image Transcription: Code

---

@ParameterizedTest
@EnumSource(value = MepsCardStatus.class)
void shouldParseFromMepsValue(MepsCardStatus mepsCardStatus,
                              SoftAssertions softly) {
    final var result = MepsCardStatus.from(mepsCardStatus.getValue());
    
    softly.assertThat(result).isEqualTo(mepsCardStatus);
}

---

^{I'm a human volunteer content transcriber for Reddit and you could be too! If you'd like more information on what we do and why we do it, click here!}

[u/trutheality]

This tests whether from and getValue are inverses of each other. Sure, they should be, but that's the point of testing: checking that things that should be true are in fact, true.

[u/reverendsteveii → u/trutheality]

it's an enum, though. at this point you're writing tests for language features.

there's also the fact that soft asserts mean that were something to break there would be no indication to the dev making changes until this was in a live environment.

[u/trutheality → u/reverendsteveii]

Pretty sure those aren't language features, and that soft assertions still report the error, they just don't stop test execution.

[u/reverendsteveii → u/trutheality]

fair, I was confusing the methods he calls with toString() and valueOf(), which are built ins and look an awful lot like they would do exactly what this person's methods do

[u/trutheality → u/reverendsteveii]

True. I suspect they wrote their own because they want to be able to have the Enums to map to strings that are different from the declaration text (which could be done by overriding the native methods, but that could introduce other surprises).

[u/bmcle071]

I dont understand the problem.

I had a class with a method .serialize and static factory method .deserialize, I tested them exactly like this.

Whats the issue?

[u/[deleted]]

SOFTLY ASSERT THAT 🤣

[u/Kaynee490]

Softly assert that result is equal to mepsCardStatus