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.

posted about 2 years ago

CC BY-SA 4.0

2y ago

klutt‭

1248 reputation 17 12 159 52