This could be handy. Boost.Test does integrate rather nicely with both Visual Studio and Xcode though (it lets you jump to the source code where the error occurred) - so I'd expect such a front end to do more than just let me jump to a spot in source code. Also, if you built a Windows application, I believe most developers who write C++ in Windows use Visual Studio. A Visual Studio addon might be more appropriate for them. If I were doing this, I might try something like the following: Build a command line application that can: 1 - Run the unit tests that result from compiling a set of source files (equivalent to a [ run ../src/$(CPP).cpp ] in a Jamfile). I may not want to run all of my unit tests, and just want an interface to run those from one file. 2 - Automatically add test cases. 3 - Run in a loop where it repeatedly compiles and runs any unit tests whose source files have changed (I could have this open in a command window as I code, and see failing unit tests soon after I save my faulty code). And then build a Visual Studio addon that makes it possible to use this command line application from inside VS. It would parse the information, and display it to the user in useful ways, and allow the user to go straight to where tests failed, or just run a single file's unit tests. Honestly though, this would probably not be enough functionality for me to feel like it was ready to release to the Boost community. But if you can think of some compelling things to add, it could make it more useful. On 3/21/07, Younes M <younes.m@gmail.com> wrote:
Hi,
I recently came across a suggestion for a Boost.Test frontend on the Google Summer of Code 2007 front page. As someone who uses Boost.Test a fair bit I think I would be very interested in persuing this. I have some early ideas about what I would like to see in a frontend, but would also love to get some ideas from others.
I've emailed Thorsten Ottosen and he suggested I try here, so here I am.
Along with the idea of having the frontend running in the systray and automatically capturing detecting and reporting on any unit tests that are run (as suggested on the Ideas page), I think being shown a list of failures and being jump to one such failure would be very handy. By "jump to" I mean having the source file open up in an editor and possibly even having the editor scroll to/highlight the line in question, or at the very least using a source-view widget in the front-end itself that could perform that function.
If anyone has any other suggestions on functionality, information to include in generated reports, user interface, aesthetics, coupling between unit tests and the frontend, coupling between the frontend and editors, or on any other topic, I would love to hear it.
Thank you for your time, Younes _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost