I’ve been applying the Replace Primitive with Object pattern to a code base - changing what used to be strings into a custom type (which not only makes the code more readable, but now ensures through type safety that you can’t accidentally pass in any old random values to methods that used to just take strings.

The code has tests, and after applying the refactoring, I have a failing test - which hints that somewhere there’s an implicit conversion from the new strongly typed object back to a string. The test’s failing assertion says it received “MyNamespace.TypedThing” (which is what the default implementation of ToString() returns), rather than the wrapped string value that TypedThing encapsulates.

My initial suspicion is that there’s probably code similar to this that’s causing the problem:

TypedThing thing = new TypedThing("thingy");
string s = $"{thing}";

ReSharper has a cool utility - “Structural Search and Replace”. Unfortunately it doesn’t work for single expressions like "{thing}".

If I was cluey, I might be able to write a Roslyn tool to search the code and find instances like that, but that’s going to take a bit more effort than I want.

What about this: temporarily override the ToString() method on my custom type, and make it throw an exception!

It’s a bit of a sledgehammer, but it worked!

As it turns out my suspicion was not quite correct. The offending code was actually assigning the custom type to an Object type (which explains the lack of compiler type warnings), which later on must be converted to a string.

Now that I could see an example, I could use ReSharper’s SSR to confirm that was the only instance of that kind of assignment (SSR can be used as I’m searching for an assignment statement, not just a single expression). Just for good measure, I’ll also re-run the entire test suite to make sure there aren’t any other similar problems still hiding.