Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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?

+1
−2

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

3 comment threads

Generic wrapper with Supplier and Consumer, perhaps? (3 comments)
Using the builder pattern (2 comments)
`Foo` could have a constructor that receives `x`, so it becomes `bar.fun(new Foo(42))`, or static fac... (4 comments)

3 answers

+4
−0

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

I completely understand your skepticism, and don't get me wrong. In many (most) cases what you're say... (3 comments)
+3
−0

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).

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

+3
−1

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

I honestly didn't even think about this simple solution. I'll use it. Thanks. (1 comment)

Sign up to answer this question »