Do you write helper methods when invoking production code in tests to hide some irrelevant details?

Let's say that I have an example test case (written in Kotlin, but it doesn't matter here)

@Test
fun `should do something`() {
    // given
    val expected = "expected result"

    // when
    val result = productionClass.process("foo", null)

    //then
    assertThat(result).isEqualTo(expected)
}

As you can see I'm passing a null value as a second parameter to process method because it's not relevant in this case so I can ommit this.

But my concern is that every time I'm reading this test I'm wondering why this null value is passed and what does it mean in this context, so my solution to this problem is to create some helper method which hides this null for me. Then my test would looke like this

@Test
fun `should do something`() {
    // given
    val expected = "expected result"

    // when
    val result = process("foo")

    //then
    assertThat(result).isEqualTo(expected)
}

private fun process(foo: String): String {
    return productionClass.process(foo, null)
}

Then when I'm reading the test it's clear for me what is happening, but as always there are pros & cons of such solutions. These are the ones that I found:

Pros

• improved readability of the test
• small decoupling of production code from tests (change of the production API causes only this helper to break, not 100 other tests)
• hiding low level details from test, I'm only intrested in the result, it's not important here how it happens (maybe... or maybe I'm wrong here)

Cons

• I'm not really sure what the test does as it can do many weird things in this helper
• Creating one helper can lead to creation of many other helpers, and then I won't be able to find what is going on

I'm really curious about your opinion. How do you handle this problem? Or maybe it's not a problem at all?

I'll give some arguments against the Pros listed...

The tests are (in my view) supposed to show exactly the method that is being exercised by the when condition for a test (in a Give-When-Then setup). So in terms of readability it means I have to read more code if another method is introduced (or several wrappers with various argument combinations) and does very little (if anything) to improve the situation, as now there's more lines of code rather than less and if there are several its going to get confusing real fast. Readability for me typically means more concise code/better named code, rather than an additional layer of redundancy that hides important details. Unless the argument list was particularly long. Then there are other well documented solutions for those situations like builders/factories/etc.

"Small decoupling" - Decoupling is to do with the dependence of one bit of code on another. Refactoring with most IDEs today is very easy with the right know-how... so its not necessary to have a method to make life easier - life already is relatively easy. Look at "select next instance of" functionality for when you've highlighted some bit of code, or "refactor method" which will typically allow the developer to reorder or change a method name/argument list to remove an argument from a method and cascade that change to all other call-sites. There's a measure known as fan-in/fan-out which can show how much one class depends on another when making or receiving method calls. This can highlight highly coupled code... delegating to another method does nothing to decouple code class-to-class.

Hiding low level details - unit testing is "white-box" testing. Testing source code where you do want to know the details. You don't really want to be hiding details at this level as the details matter. The more layers of indirection, the more places for bugs to hide. If the API is difficult or annoying to work with, the unit-testing should make this apparent and you can/should refactor, if you notice it, to make writing the tests clearer/easier.

Perhaps thinking there's a need for this sort of method is a clue that you need to break the method apart into multiple methods, so you can test functions more cleanly???