TheFuture

From CxxTest wiki

This page is a listing of vague ideas and features that may be interesting for future versions of CxxTest, but are not quite congealed enough to warrant adding to the issue tracking system. Please feel free to edit this page and add ideas.

Drop the perl script.

Python has become pervasive enough that it is reasonable to assume just about everyone has access to it now. Also, python is becoming(has become?) a more common skill than perl. Having two different scripts that do the same thing is an extra maintenance burden.

I would still vote for perl. E.g on default installation of HP-UX or IBM AIX there is no python! But, you will always find perl there!

-- True, but features would have to be backported to the perl version, and I can't do it, because I don't really know perl. Maybe periodic backports could be done by someone, however dropping the python script just seems stupid to me - however selfish those reasons might be. As far as I know both chief maintainers are more confortable with python, as am I. Atom 09:06, 22 January 2009 (UTC)

Document the current relationships among the classes used by CxxTest.

For a new developer working on CxxTest it is not completely clear how test runners, listeners, and error printer/formatters work together.

Move to a token based parser for cxxtestgen.

The current line based system has a number of limitations, especially when dealing with some coding conventions that like to add newlines in curious places (like between return type and function name). Perhaps we should look into gccxml (although I am loathe to add a new dependency to CxxTest).

How does gccxml work with other compilers than gcc? Making gcc a dependency of the framework would not be so great

Another approach that has been suggested is to make use of PLY and cppheaderparser. This has the potential of providing a pure python solution, but presents its own possible problems in terms of managing coordination of the different projects.