Good QA people are worth their weight in gold.
But also, given how standard setUp method is and how often it is used, putting set up config there is not forcing anyone to "read your entire test suite". It forces them to read setUp method and that should be no shock to whoever is making the test. I dont mind doing it the way author suggests, but I also think that difference between the two is minimal.
Helper methods deserve equal treatment in code and tests. Operating on two different layers of abstraction as well as other complains he has about their bad use would be same bad in main code.
Likewise, most other problems are also bad in code under test code. Helper methods should not bury critical values or interact with state unless it is very clear from their name. Overly concise names are bad too and trying to save key strokes is pointless. Pointless constants (FOUR=4) are pointless.
When you then edit such a function it affects multiple tests at the same time. But you rarely check if that modification neutralizes some of them or not.
Assuming these ARUs are linear (like every unit of measure for distance), you don't need a chart. You just need a multiplier. In that case, it sounds like this is describing a scale ruler  -- and your carpenter probably loves it.
For anyone who ever has to read (or draw) an architectural diagram, they're great! Rather than adding a level of abstraction, they remove one. I'm glad rulers haven't simply "existed in the same form for hundreds of years".
Badly designed helpers and abstractions are certainly ... bad. But well designed helpers and abstractions make the code much simpler to read, understand and maintain. That's their entire purpose.
There's certainly a lot of badly designed abstractions out there. If you come across one that makes the code harder to understand and maintain, you should certainly get rid of it and inline it instead. Regardless of whether it's production or test code. The flip side of this is that if you see an opportunity for abstractions that make the code easier to understand and maintain, you should certainly use it, even in test code.
I think he makes a very strong point that if the code is too complicated to use in tests then the production code should change. Simply because if it's hard to set up for you in tests; then it's almost impossible for someone else to use in real code. When they should be reusing your component they will give up and write a 'better' version for themselves.
Not to mention that the right abstractions will actually make your code simpler, instead of more complex. Imagine if someone needs to use an arraylist in a test, but decides to reimplement inline using arrays instead. Sure, they have avoided the use of a higher level abstraction, but the resulting code is now both harder to read and more likely to contain bugs.
He isn't really advocating never using helper methods either. In fact he gives an example where the helper methods hide some irrelevant values.
If I were to rephrase it as "repeated code isn't necessarily bad in tests" does that make it more palatable?
But for tests you are optimizing for a different thing. You want to know what the input to the test is. This makes referring to the test as documentation much easier.
Helper functions can work in tests but often they are completely opaque and make tests hard to understand.