I started working on a JUCE-based GUI application. I would like to follow a TDD approach, so I was wondering how and where I should put the actual test cases. I know how to use UnitTest and UnitTestRunner classes, but it’s not 100% clear (to me) how to integrate them in the main application.
Should I create a parallel JUCE project (command-line project) or keep the test cases in the main application and run them somewhere/somehow inside my JUCEApplication instance?
TDD is an interesting and useful approach, but I see it as being mostly useful with dynamic weak-typed languages like Ruby/JavaScript. I think the most important kind of tests are integration / “end to end” tests. I’m not sure how easy it would be to set these kinds of tests up in a JUCE app.
It would be great to have something like this though - testing button presses, text entry and text appearing on the screen.
IIRC the Button class has a triggerClick() method that emulates an actual click, with the component blinking and all the rest. perhaps methods like that could be added to the other GUI components to improve testability
If your project is an application anyway then you can just invoke the tests based on a command line argument (look at the Projucer code for an example of launching a GUI vs a command line app in the same codebase). If it’s a plugin then perhaps a separate command line app is the way to go. If you later move to server-based builds and continuous integration then you can then easily build and tun these tests on the server.
Hi guys, thanks for your replies. @martinrobinson-2: I’m interested in launching a GUI vs a command line app in the same codebase, so that I can let the test suite live alongside the main application. Does the Projucer work that way?