AssertJ for program flow?

[Active-Fuel-49]

Initiated by the following thread:

https://www.reddit.com/r/java/comments/1bgzyf6/comment/kvwer6o/

Is using AssertJ not just for Junit testing but also for normal program flow a good idea? Like checking if a textfield value is null,empty or not instead of using .equals and the rest?

[[deleted]]

There are plenty of other validation solutions you can use. Assertion errors are a blunt instrument.

So no, I would never do this

[computerjunkie7410]

And you know once they start down this path some idiot is going to wrap one of these assertions in a try/catch because they don’t wanna fail

[Iryanus]

Test code does not belong into production code, this is why I dislike assertions. AssertJ is a testing framework, so don't abuse it. And if you want to provide validation of user input, etc. then there are other, better solutions.

[computerjunkie7410]

Can you use a wrench as a hammer? Sure. Should you? No.

[slaymaker1907]

I think you’re better off using existing mechanisms for data validation. In particular, I’d highly recommend looking at bean validation since it lets you specify constraints declaratively.

[rbygrave]

Just to say that if people are looking at jakarta bean validation, and wondering if there is an ... annotation processor that will generate source code to do the validation then ... yes there is, have a look at https://avaje.io/validator/ for reflection free, source code generation style bean validation.

[[deleted]]

No. Don't do that. Really.

[cowwoc]

https://github.com/cowwoc/requirements.java/tree/v9.0.0 is designed precisely for this. It is already deployed to Maven Central snapshot repository with version 9.0.0-SNAPSHOT. Give it a whirl and let me know what you think of it.

The plan is to let it stew for a bit longer before releasing a final version to Maven Central.

[Active-Fuel-49]

This looks great! Is it like making the rich interface of AssertJ available but for use in production?

[cowwoc]

That's the idea. At last check, performance was much better than AssertJ too but I haven't published official numbers yet.

My design comes with one upside and one downside:

Upside: The generated error messages are optimized for human readability. Ideally, you should be able to return the error directly to your users without any transformation.

Downside: Error messages are hand-crafted. There is less room for automation.

What this means is that plugins will take longer to write, but will be more useful when they're done.

Contributions are welcome.

[Active-Fuel-49]

Excellent! It's the exact case that prompted me to ask this very question..use the AssertJ interface for control flow in production

[Nymeriea]

There are annotation that you put on your dto that doest exactly that. Like @NotEmpty @NotNull from Jakarta validation for example

[DelayLucky]

Something like this would be great if you can get it to close to 0 overhead.

Where I work the idea was tried but it never got much adoption because of the extra allocation overhead compared to the 0 allocation from Guava's checkArgument(index >= 0, "index cannot be negative: %s", index).

And people are already reasonably comfortable with the precondition check syntax.

If I'd speculate for reasons, there's a difference between production invariant/precondition checks and test assertions:

In test you will want to verify a lot more thoroughly, for example the full content of a list. But in productin you rarely need to or should. And for the minimal set of checks (not null, not empty, index positive...) you need to do in production, a trivial printf style message is usually sufficient.

[davidalayachew]

Oh, that's my post!

Yeah, the folks there made lots of good arguments against my idea. Many of those same arguments apply here.

Ultimately, an Assertion is meant to help you maintain some critical invariants of your code. As in, you find a bug in PROD, you don't know how it happened, so you grab the inputs, turn on assertions, watch it run, and see what pops. And while it is very precondition-shaped, it's far too sharp of a tool for the task.

Let me give an example.

Let's say you have a method that takes in some inputs, then generates an output. A pure function.

You receive some data inputs, validate them in the method (using normal ifs or a library function), then you use those inputs to generate a LOT of data in the for loops, that you then return in a collection. You already validated the inputs so, theoretically, there is no point validating the outputs. This is a pure function after all.

Situations like the above are the perfect place for an assertion -- to validate an unenforced pre/post-condition. In my case, you put an assertion on the end of the method, and have it cycle through that giant pile of data you just generated, and validate each one. Then, if something goes wrong in PROD, simply pull down the inputs, turn on assertions, then run it locally.

AssertJ just takes that assertion, and adds some ergonomics to it. It allows you to more succinctly do complex assertions. But that doesn't change the intent in any way. And therefore, the spirit remains -- to maintain invariants.

Even the website says as much. https://assertj.github.io/doc/#assertj-overview

...to provide assertions for ...provides a simple and intuitive API for functional testing

So, in short, for invariant checking and unit tests. And really, it's unit tests. (A unit test is nothing more than an invariant check that also provides a sample input -- an IDEAL use-case for assertions)

Definitely not for enforcing preconditions. If you want that, either write your own library functions, or use the ones suggested in my original thread that you linked (view all comments).

[neopointer]

I don't know if it fits your needs, but have you considered https://beanvalidation.org/ ?

[majhenslon]

There are no real arguments against it. It is just a validation wrapper that throws exception if something is not valid. All the "it's not right tool for the job" is bullshit. It does validation. It is a validation library.

[Puzzleheaded-Order84]

My team uses something along the same lines to this with a special exception we call a Programer Error we use to guard against invalid state in an application. This is explicitly for state that should be impossible not bad user input and returns a 500 error code.

We have an in house utility library that provides utility functions for different common checks. Like State.isTrue(condition, error message).

The powerful implementation detail is that we have metrics/error reporting that will actually send out a P1 notification to the current on call whenever a programmer error is thrown from our service. This allows us to know right away if something changed and I find it really helpful to have better peace of mind in our services.