[lldb-dev] More tests

[Zachary Turner]

Yesterday a change
<http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20150216/015996.html>
went up for review to add support for mips64 in the unwinder.  In the
review, I proposed adding some tests.  There was some discussion in the
thread, but I don't want to pollute someone's review thread with a long
disucssion, and I thought maybe more people would be interested.  So I'm
moving it over here.

For some context, I proposed the idea of testing this type of thing via
unit tests.  I certainly thing that do a full live-system debugging test
would be useful for this type of thing, but I think this is a great example
of where a unit test would provide a lot of value.  For starters, the full
scale tests are very heavyweight.  There's a lot of setup involved, they're
slow, they're platform specific.

I think for tests like this we can write them as UnitTests in a way that
they're faster, lighter weight, more targeted, *and* platform independent.
One of the issues brought up in the commits thread linked above is that the
test would only be able to run on mips hardware.  I disagree.  The test
could come with a file containing hand-written assembly.  We can use the
LLVM assembler to target mips, which will generate mips bytecode no matter
which platform you're on.  Then we can just feed the bytes to the unwinder.


Of course, you need a RegisterContext.  We would probably have to make some
changes to the unwinder so that the RegisterContext could be abstracted
out.  This way, a test could provide its own mock register context and
target memory reader.

You still need a full-scale integration test to confirm that unwinding
actually works in context.  But I think we should consider unit tests for
things like this.  It's difficult to write unit tests right now because the
code in many places is not well testable (for example, not being able to
abstract the registercontext so that a test could provide its own).

But I want to just toss this out there and see how much pushback I get.  If
it's something people are interested in, then it's something we could work
towards gradually.  I think we can all agree that checking in code with 0
tests sucks, so hopefully we can work towards something that gets us into a
better state.  Getting more full-scale public API tests is one angle we can
approach it from.  But I think unit tests would be some nice additional
ammo we could throw at the problem, if we work towards better abstractions
and more testable code.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150219/ea3ac88c/attachment.html>