What you're talking about is changing the interface of the code under test. You usually can't do that. If the interface outputs a string then you need to deal w

What you're talking about is changing the interface of the code under test. You usually can't do that. If the interface outputs a string then you need to deal with a string. Ideally a test should be an extremely literal interpretation of the spec. The test in the example I would read as "the output should be the result of a string concatenation between the base URL string and this string". The problem is that spec doesn't exist because it's stupid and wrong. This test suite implements a bug-ridden, ad hoc URL builder. The real spec is probably "the output should be a string containing a valid URL for the photos page". I see two options for writing this test: 1. Compare to a "trusted" string literal which conforms to the spec (ie. to be a valid URL for the photos page), 2. Decode the string using a "trusted" URL decoder and validate it at the URL level. I think they are equally valid options and a matter of taste and convenience but both accurately reflect the spec, unlike the example. The second option is essentially playing off two bits of code against each other, like testing a forwards operation against a reverse operation. This works if both bits of code are completely independent and therefore extremely unlikely to accidentally compensate for each other's bugs. If the URL decoder is in a widely used standard library then this could be considered OK (the robustness principle explicitly makes things asymmetric, though, so a URL decoder with a "strict" mode would be most appropriate). But ad hoc code written in a test suite is definitely not OK!