Post History

It seems to me that you are hobbling yourself by making design constraints more absolute than they need to be. For instance:

* You don't want to change the code under test, not even a tiny little bit.
* You don't want to introduce a helper function, because helper functions clutter the code (is that always the case? No way to mitigate that?)
* You want your test cases to fit on one screen, not scroll even a single line.

Now, all those goals are sensible, but they are not boolean: The *more* you have to change the code under test, the *more* helper functions you have, the *more* you have to scroll the worse it gets.

It can make sense to comprise a goal a tiny little bit if doing so markedly improves another. That is, good design involves making sensible trade offs.

With that said, let's investigate a few trade offs:

If you add
```
public Foo(int x) {
    this.x = x;
}
```

to Foo, all your tests can read:

    assertEquals(87, bar.fun(new Foo(42)), "Test failed because blabla");

which fits on a single line and it quite readable.

Or if you added to your test class:

```
private fun(int x) {
    var foo = new Foo();
    foo.setX(x);
    return bar.fun(foo);
}
```

your tests would read

    assertEquals(87, fun(42), "Test failed because blabla");

Notice how a descriptive name instead of `wrapper` can improve the readability of your code. In addition, you can reduce clutter by moving the helper function out of sight, for instance by declaring it at the end of the file, or in a class of its own.

Overall, the main objective should be to reduce code duplication in your tests and improve their readability by using descriptive names. If you have many tests performing the same cumbersome steps, factoring that out into another method makes perfect sense.