Feb 27, 2014 UPDATE:

As you may have noticed, this project is a bit chaotic and neglected at the moment. Nevertheless, I still fully intend to complete it. More importantly, I'd like to clean up the documentation and the project as a whole.

That being said, I'm a little busy finishing up college and working on another project at the moment. And I'm sure work will keep me sufficiently busy once I start as well. But if you would like me to priortize getting this project into a better state, shoot me an email (matcatprg@yahoo.com) so I can do so.

Things I'd like to do right away:

. Cleaning up documentation. On the order of rewriting ALL of it from scratch, using the old docs only for the information they contain.

This includes changing this README to be the sole user document, written in something human readable (probably asciidoc) rather than straight up docbook (live and learn.)

Would also create secondary documents INSTALL and TODO.

. Renaming the project.

I've had an idea for renaming the project for about 2 and a half years now. I still like the name, so I probably will when I get the chance.

As for the code itself, I'd probably just want to refactor and clean up functionality for the time being. Fix bugs and the like. Could add features farther in the future when I have a better idea of what I'm doing.

As always, feedback is welcome.

Matthew Todd

This file is a dump of random things I need to keep track of or might need later.

For the documentation, please see manual.dbk, which is periodically built and hosted here: http://matcatc.github.com/Test_Parser/

This project started as an attempt to create some sort of visualizer for the boost unittest framework. So instead of having some horrendous command line output, a developer could have something a little easier on the eyes.

I'm trying to design it so that the program can work with any test framework. One would just have to switch out for a different parser and runner.

This is my first Python project (serious coding with an final application in mind.) I'm using python 3.x. The doxygen file is setup to use doxypy. See documentation.

Please give feedback. If you find something that bugs you enough to complain about it, its important enough to send me an email. Same goes for positive aspects as well. If I get no feedback, I have no clue how well this software functions in the user's perspective.

Matthew A. Todd

Road Map:

It might be nice if the GUI could run arbitrary Python scripts. The idea being that an user could run a script which compiles the test runner then calls run on it. I'm assumming we're going to want to pass in something into it the script call so that scripts will have a reference to some of the data. Possibly the model (which would use Observer pattern to notify the display should the script change the model's data somehow.) I guess a question is whether the script would ever want to do something to the gui. I suppose its possible, so we should allow for it, meaning we need to give a reference to the Gui as well. If we have a containing class which contains all the particpating objects in the running program, it would be a good option to pass in.

License:

This project is licensed under GNU GPL v.3. See COPYING for more info