I had a little task today at work, where I needed to replace the way I created a JSON object that was being returned from an API. Long story, but the challenge at the end was to make sure I didn’t screw it up, so I wanted an easy way to compare the “before” and “after” JSON. Now, I was adding a feature here, so the before and after were going to be different, but I wanted to have an easy way to check that they were different only where I expected them to be, and there weren’t any unexpected side-effects.
This let me down a rabbit hole, looking at things like this ObjectsComparer package on GitHub. I also stumbled across this JSON extension for FluentAssertions. In the end, I just wrote a script in LINQPad to dump the before & after JSON to disk, then compared it with Beyond Compare. I keep thinking that I need to put together a better testing framework for my API, so I can better automate this kind of stuff.
I don’t have a unit test project for this API, or any other really structured tests. I have a test client that can run a suite of “safe” tests that don’t alter data, and checks a few things on the results. But it’s not a very complete test set. And I have another client that runs a test cycle that does alter data, and hence needs to be run carefully, and can’t be run too frequently. (And that one isn’t very complete or thorough either.) And I have some LINQPad tests that I run mostly as smoke tests.
I’m currently working my way through the TDD section of the Clean Code series that I’ve been watching/reading. I’ve always liked the idea of TDD, but I’ve rarely worked on a system where it seemed practical. (I’m not saying that it’s not practical, just that I haven’t figured out how to effectively apply it to any of my typical work.) Regardless of TDD, I ought to be able to put together some better and more automated tests for some of my work.