Re: [PATCH 3/8] Disassembly unit test: disassemble one instruction

[Yao Qi <qiyaoltc@gmail.com>]

On Thu, Jan 12, 2017 at 5:43 PM, Pedro Alves <palves@redhat.com> wrote:
> On 01/12/2017 05:03 PM, Yao Qi wrote:
>> On 17-01-12 13:06:26, Pedro Alves wrote:
>>> I'd much prefer if the core of the unit testing framework doesn't learn
>>> about different random subsystems.  Consider what we'd do if we
>>> wanted to reuse selftest.c in gdbserver.  I think we will at some point.
>>
>> Can we consider using some general c++ unit test frameworks rather than
>> selftest.c?  I don't see any issues if we can merge the unit test
>> results into dejagnu test result gdb.sum.
>
> We can consider anything, of course.  But I don't know whether
> that's give us any significant advantage.  I never evaluated any myself.
> Do we miss something important with the current framework?

Nothing so far.  I need an assert or check that an exception should be
thrown in some statement in patch #7, like EXPECT_THROW in gtest.

All current unit/self tests are started by a command "maint selftests".
Probably, we can't unit test event loop or command handling.

> Would it be used as an as external dependency (required? optional?), or
> would we import it into the codebase?  How would it
> affect the way we write tests?  And the way we write the code that ends
> up tested?  Would it force something on the codebase that would be
> undesirable?  Etc., etc.
>

We only have one assertion SELF_CHECK, but we need more, like EXPECT_EQ,
EXPECT_TRUE, etc.  They can be easily added to selftest.h.  I don't
think of the answers of these questions either, but we should think of them
at this stage, because we don't have many unit test cases yet, it is
easy to change to any framework.  It is difficult to change when we have
thousands of unit tests on top of selftest.{c,h} framework.  so, if we
want to use
something as a framework, be careful :)

I'll try some c++ unit test frameworks in gdb, and see what I can get.

-- 
Yao (齐尧)