This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Two more AI bugs


> Fixing this crash is actually the first item in the TODO list that
> Stan left for the next release. However, running all.g causes a hard
> freeze under MacOS so I haven't got around to debugging it yet.

OK, I've checked in a fix to change this from a core dump to a
run_error; that should be sufficient.

Now, as to where we stand on tests in general, what we have now seems
like it is pretty hard to use.  A few of the problems are:

* They are way too slow to run them with any frequency.  Some of this
  would be easy to fix (for example, I see little reason for
  test-acts.sh to run for every game in lib).

* I don't see any mechanism for comparing the result of a test with
  some kind of expected result.  This is pretty crucial, because
  unless you get a pass/fail it is hard to run the tests frequently
  and know what they are telling you.

* I'd also probably prefer tests which link into xconq.  It makes it
  easier to test internal APIs and test one module at a time.

The
http://cppunit.sourceforge.net/cppunit_cookbook.html#cppunit_cookbook
page is an introduction to the style of unit test which I'm thinking
of.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]