Re: [lmi] wx_test_input_sequences.cpp

[Greg Chicares]

On 2015-03-27 00:30, Vadim Zeitlin wrote:
> On Fri, 27 Mar 2015 00:07:22 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> /// TestModelViewConsistency(): Diagnose inconsistencies between the
> GC> /// Model and the View. This function is designed for developers
> GC> /// rather than end users, and makes little attempt to avoid false
> GC> /// positives.
> GC> 
> GC> ...which has never been called routinely, because there has been no
> GC> appropriate place to call it. Perhaps it belongs in the GUI test.
> 
>  It would, of course, be trivial to call this function from a test. The
> only question is from which one should it be done. Adding a new one just
> for this seems slightly ridiculous, but I'm not sure where else to put it.

I wouldn't require a unit-test TU to have any particular minimum size.
If it's independent and self-contained, and really doesn't belong with
anything else, then that's good enough for me--even if it performs only
a single test. 'crc32_test.cpp' does just that, and I don't regret the
overhead of the inline copyright disclosure in that TU, of referring to
it in makefiles, or of carrying an extra file in svn.

But, since I was looking at small unit tests
  ls -o *_test.cpp |sort | head
I took a closer look at 'file_command_test.cpp', which even I would say
is ridiculous. We use mime types only in lmi's GUI variant, so this test
should be moved into the 'wx_test' suite--where it should actually test
something. (Today, I'm not prepared to say what it should test, but we
could fill that in later.)

If you prefer fewer and larger unit-test TUs, we could combine these
two into a new 'wx_test_miscellanea.cpp'.

Alternatively, if you'd like to write a tiny piece of code for
lmi_cli*$(EXEEXT) to call AssocQueryString() (and a POSIX equivalent),
then I'd be glad to have that extra capability. (But not so glad that
I'd be willing to make lmi_cli* depend on a basic wx library.)

>  But I also wonder if it shouldn't refactored and moved in a (new) test
> entirely, as it isn't used anywhere in the main application anyhow and it
> doesn't seem to require any special access to the private parts of the
> class (it does use lineage_, but we could just recreate a new Lineage
> object in the test instead of using this private field). What do you think?

There are some tiny snippets that I occasionally insert into my local
tree and build for my own use. Here's an example:
  http://svn.savannah.nongnu.org/viewvc?view=rev&root=lmi&revision=6156
where it became inconvenient to maintain an offline snippet, so I
put it into the repository with a special option to enable it.
Similarly, I sometimes want to use TestModelViewConsistency(), and
I probably ought to add an option to enable it in lmi. For that
reason, I prefer not to refactor and move it.