Useful failures for set inequality in plunit

Ross Boylan <[email protected]>
Newsgroups gmane.comp.ai.prolog.swi
Message-ID <1376180492.4084.51.camel@localhost>
This test:
<test>
test(content1, [true(X == Expected), setup(full_print(OldOptions)),
cleanup(restore_print(OldOptions))]) :-
	content_ancestors(path(['ossecond1', 'archive']), when(date(2011, 6,
1), seq(10)), Graph),
	graph_ordered_nodes(Graph, X),
	% It's not clear if /home/ross should be here, but algorithm currently
includes it.
	% xda1 is also marginal
	list_to_ord_set([xdb1, xda2, xda1, path(['osfirst1', 'home']),
path(['osfirst1', 'home', 'ross']), path(['osfirst1', 'mnt']),
path(['osfirst1', 'sillyfile']), path(['ossecond1', 'archive'])],
Expected).
</test>

yields
<output>
ERROR: /home/ross/disks/rulesTest.plt:71:
	test content1: wrong answer (compared using ==)
ERROR:     Expected:
[xda1,xda2,xdb1,path([osfirst1,home]),path([osfirst1,home,ross]),path([osfirst1,mnt]),path([osfirst1|...]),path([...|...])]
ERROR:     Got:
[xda2,xdb1,path([osfirst1,home]),path([osfirst1,home,ross]),path([osfirst1,mnt]),path([osfirst1,oldhome]),path([osfirst1|...]),path([...|...])]
</output>

This is not as helpful as it could be, raising three issues in ascending
order of generality:

1) The max_depth setting is truncating the output; it would be helpful
to see all of it.  I have tried resetting it with the setup and cleanup
code
<code>

% enable fuller printout of failures
% full_print(-OldOptions).
full_print(OldOptions) :-
	current_prolog_flag(debugger_print_options, OldOptions),
	select(max_depth(_), OldOptions, Old2),
	set_prolog_flag(top_level_print_options, [max_depth(30) | Old2]).

% restore_print(+OldOptions), the argument returned from full_print.
restore_print(OldOptions) :-
	set_prolog_flag(debugger_print_options, OldOPtions).
</code>
but that is ineffective, as was an earlier version with
toplevel_print_options.

The source of plunit includes
<code>
write_options([ numbervars(true),
		quoted(true),
		portray(true),
		max_depth(10),
		attributes(portray)
	      ]).
</code>
which suggests the value is wired in.  Is there anything I can do about
that?

2) It would be more useful to have the shorter output of values expected
and not found, and then values found but not expected.  The test could
code that, but is there a more elegant approach?

I suppose I could compute the asymmetric differences in the code and
then make the true option for the test work in terms of those
differences.  But it still seems a bit manual.

3) Is there a better way to be comparing sets?  The set option for tests
is not appropriate because the value being tested is a single set, not a
bunch of alternative values that satisfy the predicate.

Thanks.
Ross Boylan

P.S. The code is rulesTest.plt, commit
5f6481edb2cc45d56af2cd5c1ef64207109367e0 on
https://bitbucket.org/RossBoylan/disks if you want fuller context.
rulesTest.in is the slightly human-friendlier input that './fact.py
rulesTest.plt' processes into the .plt file.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.