Test @UtilityClass

[Onyeka Nwamba]

I'm using the experimental @UtilityClass annotation, how do you test the auto-generated coed?

[Thorsten Glaser]

On Thu, 19 Nov 2020, Onyeka Nwamba wrote:

> I'm using the experimental @UtilityClass annotation

Oh, cool, this is new but highly appreciated.

>, how do you test the auto-generated code?

──────────────────────────────────────────────────────────────────

<project xmlns="http://maven.apache.org/POM/4.0.0" …
[…]
<properties>
<trajano.version>2.1.0</trajano.version>
</properties>
[…]
<dependencies>
<dependency>
<groupId>net.trajano.commons</groupId>
<artifactId>commons-testing</artifactId>
<version>${trajano.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
[…]

──────────────────────────────────────────────────────────────────

package foo;

import org.junit.jupiter.api.Test;

import static net.trajano.commons.testing.UtilityClassTestUtil.assertUtilityClassWellDefined;

class FooTest {
@Test
public void testUtilityClass() throws ReflectiveOperationException {
assertUtilityClassWellDefined(Foo.class);
}
}

──────────────────────────────────────────────────────────────────

You’re welcome,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*************************************************

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*************************************************

[Emil Lundberg]

Or you just don't test it - much of the point of a statically typed language is that you don't need to test what the language guarantees. And you're (presumably) not testing how your database abstraction layer generates queries, or how your web framework binds network ports. Just expect that Lombok does what it says in the docs and that the Lombok project has tests to back that up. Then spend your valuable time testing the promises and behaviours of your application, rather than testing the tools you depend on.

/Emil

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/8a2a3b4e-bd32-95b6-fe33-2482bdc9bb46%40tarent.de.

--

Emil Lundberg

Software Developer | Yubico

[Floris Kraak]

Actually, that's both true and false.

It's true in the sense that yes, you should only test your own code in unit tests.

But.. it's also false in the sense that unit tests on their own are not enough. You should also have at least one test somewhere that tests the whole thing. Talks to an actual endpoint using a network call, hits the actual database, and basically exercises all of that library and framework code that makes everything actually become an application. 

Because really, those are not static things. You should upgrade your libraries and frameworks if you want to stay safe and secure, and the only way to do that safely is by having a test to cover your behind of some third party screws up.

To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/CANMnvkx7uEK5%3DtJpRe9diubFV7ezOp5OdPA%2BW%2BgRGm5Z-KP0Ug%40mail.gmail.com.

[Thorsten Glaser]

On Wed, 25 Nov 2020, 'Emil Lundberg' via Project Lombok wrote:

> Or you just don't test it - much of the point of a statically typed
> language is that you don't need to test what the language guarantees. And

A private constructor normally lowers the coverage count though;
measuring tools are not prepared for this, for some reason; I
have no idea why.

With the Trajano test thing I was able to get to 100% except for
assert statements and @SneakyThrows (if someone can tell me how
to “test” for that, or how to make IntelliJ/Sonar/JaCoCo/whatever
ignore it, please share).

Now reaching 100%, unless there’s corporate demand, does not make
sense in itself… except when it can signal that I haven’t forgotten
any“thing” (for some values of thing; usually lines and conditions).

> you're (presumably) not testing how your database abstraction layer
> generates queries, or how your web framework binds network ports. Just

These are not “my” code, though, so this differs.

Yes, I fully understand your point, I just am pointing out that there
are scenarios in which this makes sense, albeit not the “obvious” one
(but a side-effect one).

bye,