Martin Baker wrote:
>
> On 24/09/16 22:33, Waldek Hebisch wrote:
> > ATM I have omited part dealing with
> > "randomSimplicialComplex". This function is fishy, giving
> > result which is far from beein random. And usefulness is
> > far from clear, for testing testing all cases is more
> > efficient and more convenient.
>
> This function is for regression testing. I think it is very important
> that regression tests are in the same source file as the code being
> tested. It may seem that it is just as good to have a separate script
> file like bugs2016 but I think human nature means things donâ t get used
> and updated by anyone modifying the code if hidden away in a separate file.
>
> Of course you may have other regression tests but I think its also
> important to have tests written by the original author and anyone else
> working on the file.
>
> These tests have already caught a couple of bugs which might otherwise
> had got into the code.
>
> It would be good if there was some standardised way of doing this that
> does not pollute the namespace or use runtime resources. I do feel
> strongly that this code does need to be in the same file or they could
> be ignored.
>
> I would also like to write more regression tests for other code that I
> have written. If there were a standarised way to add it to the source
> files then I would do this.
There are two things here:
- 'randomSimplicialComplex'
- organization of tests
Concerning 'randomSimplicialComplex': random testing has some
advantages and drawbacks. Main drawback is that results
change, so checking for correctness is harder. Normal
random tests have advantage that they can generate large
number of examples including many which human would not
generate. Your 'randomSimplicialComplex' looses
advantage of random testing because it just uses already
prepared examples.
Concerning organization of tests, I do not buy argument
that "it must be in the same file". What is in which
file matters mostlty for Makefiles and grep searches.
Putting things different than source code means a lot
of false hits from grep, which is a significant
distraction. Also Makefile may get unnecessarly complicated.
When doing "quick and dirty" fixes people will go
directly to relevant function -- if you add something
20 lines below it may be as easily missed as something
in completely different file.
What is important is that test should be easy to write
and easy to run. Current test framework is far from
ideal but it has provisions for collecting statistics
and printing results. AFAICS you used 2-3 times
as much code for a test than .input file using the
framework. And 'make all-input' runs all tests.
Anybody commiting to FriCAS is supposed to run
tests and check results. But if your tests
require separate action to run, then they will
be ignored.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
