>> I disagree with "Don't put logic in tests", with the example provided being a problem with using strings where a URI type is needed instead. Perhaps the source of my disagreement is I hold that test code is production code due to test suite failure(s) during an automated build stops desired deployment.

> Yeah, I think that's a fair criticism. I think the specifics of the example could be better, but I think the important underlying message is that even something that seems simple like a string concatenation is added complexity that can mask a bug in a test.

I didn't mean to criticize so much as identify why I consider test code to be the same as production code.

Continuing with the example provided, the string concatenation is not the problem this test identifies IMHO. Instead, it is that:

  nav.getCurrentUrl()

Returns a `String` instead of a type which disallows the formulation of the problematic `assertEquals` to begin with.

In a more general sense, I have found treating test suites the same as one would production code (refactoring, commenting, sometimes testing support logic used to define tests, etc.) has led to tests benefiting the same way. This approach also has had a twofold benefit of "keeping the same energy" when producing all source artifacts along with serving as a great way to onboard new team members.

All the usual caveats apply, of course. YMMV, IMHO, etc. :-)