Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
How to create an object, call one of it's methods and pass it as an argument as a oneliner?
Assume I have this class Foo
class Foo {
private int x;
void setX(int x) {
this.x = x;
}
}
And I have a Junit test like this:
Bar bar;
@BeforeEach
void setup() {
bar = new Bar();
}
@Test
void test() {
Foo foo = new Foo();
foo.setX(42);
assertEquals(13, bar.fun(foo).getY(), "Test failed because blabla");
}
Now, I would like to make the test function to a oneliner without modifying either the class Foo or Bar. I have tried assertTrue(bar.fun(new Foo().setX(42))) but then I would need to change the return type of Foo::setX.
The closest working solution I have so far is to write a wrapper like this:
void wrapper(int expected, int x, String msg) {
Foo foo = new Foo();
foo.setX(x);
assertEquals(expected, bar.fun(foo).getY(), msg);
}
But I want to avoid it if possible. Mainly because it's likely that if I go that route, I would have to write many wrappers that would clutter the code. And the reason I want oneliners is to get a better overview of all testcases without the need for scrolling.
EDIT
The comment section made me want to clarify a few things. I completely understand that this is not the best thing to do in most situations. My question is for those cases where it actually makes sense.
I do changes to code to make it testable, but that's mostly restricted to making fields an methods protected instead of private, plus extracting methods.
I think InfiniteDissent had a genius answer. Simple but straight to the point. meriton pointed out that code duplication should be avoided, and while I do agree in general, there are always exceptions to every rule. Look at this example with some slightly modified code from InfiniteDissent's answer. I know that one shouldn't answer in the question, but this is the best way to explain why I wanted this.
@Test
void test() {
Foo a;
// X & Y - When enemy comes from north and has low health
a = new Foo(); a.setX(42); assertEquals(13, bar.fun(foo).getY());
a = new Foo(); a.setX(43); assertEquals(10, bar.fun(foo).getY());
a = new Foo(); a.setX(44); assertEquals(16, bar.fun(foo).getY());
// X & Z - enemy comes from north, but has high health
a = new Foo(); a.setX(47); assertEquals(133, bar.fun(foo).getZ());
a = new Foo(); a.setX(3); assertEquals(1, bar.fun(foo).getZ());
a = new Foo(); a.setX(2); assertEquals(16, bar.fun(foo).getZ());
// A & Y - Enemy comes from south and low health
a = new Foo(); a.setA(17); assertEquals(133, bar.fun(foo).getY());
a = new Foo(); a.setA(113); assertEquals(122, bar.fun(foo).getY());
a = new Foo(); a.setA(2); assertEquals(16, bar.fun(foo).getY());
// A & Z - Enemy comes from south and high health
a = new Foo(); a.setA(11); assertEquals(33, bar.fun(foo).getZ());
a = new Foo(); a.setA(133); assertEquals(126, bar.fun(foo).getZ());
a = new Foo(); a.setA(23); assertEquals(16, bar.fun(foo).getZ());
}
Sure, it's unorthodox, and it's A LOT of code duplication, but given the context, it's not really a problem. The above code is VERY clear, VERY well structured, and ALL of it easily fits on one screen, and there are NO abstractions whatsoever to keep track of. Anomalies from the pattern is easily spotted with a pure glance, given proper formatting. Adding new tests are very easily done by just copying a row and change a few characters. It's not perfect. It's not foolproof. But it does have its benefits.
And yes, this is not always a good idea, but sometimes it is. This question was for those cases where it does make sense.
3 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
If you do not mind having so much code on a single line, the builder pattern might be useful here. Something along the lines:
Note: the example is adapted based on an implementation I have done in a .NET and deviates from the canonical example shown in the reference.
Define the builder
public static class FooBuilder
{
private final Foo foo;
public FooBuilder() {
this.foo = new Foo();
}
public FooBuilder withX(int x) {
this.foo.setX(x);
}
public Foo build() {
return foo;
}
}
Usage
new FooBuilder().withX(42).build().getY().
The advantage of this pattern is that when Foo's state gets larger, it is pretty easy to maintain the tests, especially when you need to build objects without setting all the properties (e.g. maybe X becomes irrelevant for some tests and only Y and Z are relevant).
0 comment threads
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.
1 comment thread
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| klutt | (no comment) | Feb 23, 2022 at 22:55 |
It's not clear from the question if the requirement is based on lines or statements.
If what you care about is lines of code, you can put all three statements on one line. This doesn't do much for readability, but then playing Code Golf rarely does.
void test() {
Foo foo = new Foo(); foo.setX(42); assertEquals(13, bar.fun(foo).getY(), "Test failed because blabla");
}
If the requirement is for a single statement, then I don't see any way to achieve this without either writing a wrapper or changing the code under test. assertEquals() requires two values to compare, setX() does not return a value so either you need to change it so that it does, or put it behind some other function that will (directly or indirectly) return the value you are going to assert.
My own suggestion would be to give up on the goal of "avoiding the need for scrolling". Packing source code into fewer lines will not increase the quality or readability of your code, and even if you succeed in making every test a single line, a requirement to avoid scrolling will still limit the number of tests you can have, which potentially decreases code quality by reducing test coverage. But of course it's your choice how to style your code.
1 comment thread
3 comment threads