On 22/01/2021 18:42, Jim Ingham wrote:
If you are just loading an object file and the looking at the line table or
something like that, would a UnitTest be more suitable?
Jim
It depends on who you're talking to. :) I, for one, think we should be
writing more unit tests, however, this is not a universally accepted
position (quite the opposite -- some folks will go to enormous lengths
to avoid writing one -- creating single-purpose utilities, etc.).
A major stumbling block for writing unit tests is the ability to
generate test inputs (and this is both a consequence of and the source
of the aversion to unit tests). We now have the ability to generate
binaries from yaml programatically, but for a long time, we didn't have
even that (and our unit tests were shelling out to the yaml2obj binary),
but there's nothing similar for other llvm tools. All of the relevant
code is already present in llvm, so it wouldn't be impossible to create
something like that, but it is work...
But even I have to admit that the "lit" style tests have their
advantages, if used reasonably (no proliferation of one-shot utilities
and flags, etc.). The tricky thing about unit tests is ensuring they
produce good (actionable) error messages when that fails. That usually
means writing to_string methods for all objects being compared. If those
to_string methods are good, then there shouldn't be much difference
between comparing their outputs vs. comparing the objects themselves.
And this is pretty much what FileCheck does. Plus, this has some other
advantages, like being able to run the tool on random inputs to check
its output, not needing to recompile when you modify the input, etc.
pl
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
