From: Jeremy Pack (rostovpack_at_[hidden])
Date: 2007-03-21 13:34:54
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
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_at_[hidden]> wrote:
> 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,
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk