Sunday, November 25, 2012

Improved test support in EclipseFP

Last year during his GSoC, Alejandro Serrano did a great job of integrating test-framework results in the JUnit view. This has served me well in my own endeavors (buildwrapper has 50 something HUnit test cases).

But there were a few limitations:
- using the JUnit view added a dependency on JDT plugins
- the view only gave an error when double clicking on a test result because there was no link between a test and the source code it was in
- the test results only appeared once the full test suite had run

I have reviewed the options, and the upcoming version of EclipseFP will have the following changes:
- A specific view for Haskell test results. Basically a rip-off of the JUnit view, without the progress bar because it's a custom control the JUnit UI guys wrote and life's too short. It's got history so you can get back to previous runs, and shows errors or failures in the bottom text area.
- Integration with HTF. While the test-framework integration will still work, using HTF gives us:
   - Jump to location (from test result to test definition location or failure location), thanks to the HTF preprocessor
   - Running updates thanks to HTF generating JSON output after each test and not in one big file at the end.
   - Automated discovery of tests based on naming conventions
   - Easy reduction of test cases to run from a command line argument
   - Elapsed time of tests
   - while still retaining integration with HUnit and QuickCheck

Thanks Stefan Wehr for your great work! Make sure to read his tutorial on HTF.

I've ported the buildwrapper test suite to HTF, and voila!

Since HTF relies on a few pragmas, I'm now going to work on a couple of wizards to simplify creation of the HTF Cabal test-suite and a HTF module. Watch this space!

Monday, November 19, 2012

I've finally figured out the UI the users want


After years of struggling with "we'd like to be able to tweak X and Y, and be able to do Z as well, but it has to be really intuitive and easy to use". Yes, it's the responsibility of the developers (or of the user interface design guru if you're lucky enough to have one) to provide a powerful yet easy to use interface, with intuitive navigation, sensible defaults, expert modes, etc, but sometimes it just gets too much. If you want to be the one that decides when to change gears, you have to know how to use the clutch.