I have a huge record of feature flags and some of my tests ensure that these all have the expected value. However using any “naïve” equality assertion in my test suite, I’m finding myself with unreadable dumps on my screen. What is the recommended way today to get a readable diff of the expected and actual values? I don’t mind writing my own tasty wrappers.
I have experimented with generic-diff recently with some level of success. As the name implies, it is based on generics, so you can derive a few instances and start using it right away with no additional boilerplate. It also ships with special diffing logic for some common container types (e.g. Map and Set) that provide nicer diff outputs compared to what you would have with just the generics-based instances. For my use case, one shortcoming of the library that ultimately didn’t allow me to fully substitute it with our in-house solution is that in the case where two values are structurally the same but have different values (e.g. just two Ints with different values) the diff output just reports them as “not equal”, and does not display the actual values. I attempted to add the said functionality but ultimately failed, possibly due to my lack of understanding of generics-sop.
The announcement post of the library by @fpringle from a year ago might also be of interest: Generic-diff: generic structural diffs
At work, we have a similar problem. Because it’s for tests only, and performance isn’t an issue, we’ve been printing the line-diffs of pretty-printed data structures. This is the same approach that hedgehog uses.
Janky? Yes. Easy? Also yes.
Yeah, it’s a bit “worse is better” compared to the likes of generic-diff, but I’ve found this the most painless approach as well. I tend to use pretty-simple for the pretty-printing.
Thank you to the both of you. I found tree-diff but Tasty colours indiscriminately in red all output from a failing test, which makes it slightly harder to see diffed values (but it works, if only half-way).
Hi @ozkutuk, sorry to hear you didn’t make headway with the feature you planned to implement. Do you have a WIP branch I could take a look at? Maybe we can make it work.
Thanks for offering to help, I have now posted a reply to the issue with the link to my WIP branch!
Amazingly enough, @fpringle has already created a PR addressing this since I have posted this comment, so hopefully I can fully vouch for using this library pretty soon. Thanks for tackling this, and also being extremely fast at that!
For my own test framework, I pretty print and then let the diff stuff highlight: karya/Util/Test/Testing.hs at work · elaforge/karya · GitHub It’s simple and good enough almost all the time. For pretty print, I also have my own function, but it descends from ipprint: karya/Util/PPrint.hs at work · elaforge/karya · GitHub
I think I tried generic diff at some point, but concluded it was much work for little return.
Hi @elaforge (and @george.fst (and anyone else)), would you mind elaborating on why generic-diff was too much work? Any feedback on what would make the library more usable would be much appreciated 
Probably that all your dependencies need Diff instances, as well as Generic instances. For example, generic-diff can’t be used in GHC because the AST is too big. There’s nothing you can do about that though 
.
Ah, yeah, there’s not much we can do about it, without some sort of messy TH solution.
Likewise, I don’t remember really because I looked into it many years ago, but at a guess it was that I discovered that prettty print + the diff I already have was good enough, and adding instances to types seemed like more friction than was worth it for something which already solved the problem. It’s hard to be beat zero syntactic overhead.
Another benefit is that I use a Pretty typeclass which is like Show but formatted and and with lots of missing info and non-haskell syntax to show the gist, and diff works on that too.