Re: PATCH: use Expect subprocess for internal unit tests

[Jacob Bachmeyer]

Ben Elliston wrote:
> On Fri, Dec 14, 2018 at 11:05:27PM -0600, Jacob Bachmeyer wrote:
>   
> > Similarly, slave interpreters do not have the "Expect" commands, so
> > new stubs for "send_error" and "send_user" were added alongside
> > "send_log" in default_procs.tcl.  A "TODO" note is added to
> > clone_output.test, suggesting future work to produce useful mocks
> > for those procedures that can verify what clone_output actually
> > outputs.
> >     
> Can the slave interpreters run 'package require Expect' to avoid that?
>   

I do not know what Expect does with multiple instances in the same 
process, so I would rather not take that approach; it just feels like 
asking for trouble, in the future if not now.  (Threads are likely to be 
a similar can of worms, unfortunately.)  The "Expect" commands (or some 
abstraction layer that collects it all into an asynchronous event loop 
in the master) could be aliased into the slave interpreters if needed.

But for this case, adding the stubs is almost certainly the right thing 
to do:  they avoid producing output that otherwise clutters the log and 
"pave the way" for future more-specific mocks that will enable 
clone_output to be thoroughly tested.  Currently, there is no actual 
check for when clone_output produces output and when it does not:  the 
testsuite will pass either way.  Since procedures can be overridden by 
simply invoking "proc" again for the same name, clone_output.test could 
have its specific implementations that work with a similarly specific 
"test predicate" (like the various "lib_*_test" procedures in 
default_procs.tcl) specifically to verify the output produced by 
clone_output.  (This is what the "TODO" note from this patch envisions.)


-- Jacob