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.
Comments on How to create an object, call one of it's methods and pass it as an argument as a oneliner?
Parent
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.
Post
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
3 comment threads