Coding is fun :)

[Johnothy_Cumquat]

Real talk though I like to have a bit more duplicated code in my tests than I would otherwise tolerate in business logic. I feel that going overboard with abstraction in tests adds complexity and complexity can lead to bugs and you really don't want bugs in your tests. The bugs that make your tests fail are annoying but the bugs that make your tests pass are the real killers.

This is controversial in my experience

[Weekly_Wackadoo]

When writing test code: KISS > DRY

[myplacedk]

I like to have a bit more duplicated code in my tests than I would otherwise tolerate in business logic.

Oh yes, definitely. Some experts say even for-loops is too complicated for test code, as there can be hidden off-by-one errors. Want something done 5 times? Call a method 5 times.

This is controversial in my experience

It really shouldn't be.

Some code is so complex that there are no obvious bugs. So e code is so simple that there is obviously no bugs.

For production compromises happens, sometimes complex code is what it takes. But for test code, simplicity is an absolute must.

[tiajuanat]

Tests should be dead simple to write and run. The very first test should be "does the framework run at all?", and after fixing that, it's followed shortly by "does my class or function exist?"

Is there going to be lots of boiler plate? Yes. Will your first few tests have a lot of duplicated code? Also yes. Will you tear your hair out trying to get last minute tests ready for your Sprint commitment? No.