> We miss a functionality in Pharo to easily run (a shorcut) a set of selected > tests (ex: your project tests). This way, you can have a quick feedback on > your updates. > As it is not so easy, I often fallback to run tests from Nautilus (a test > class or sometimes only a test method).
This may be an idea: I once wrote a bit of Smalltalk code inspired by this: http://www.junitmax.com/ We ran it in our dev environment for about 2 years, and took it out when we upgraded to Pharo 3.0. I still miss it. Other members on the project do not, generally. When accepting a method, we ran some tests: 1. lint (on the method) 2. if the changed method is a test method, run it (debug) 3. if not, run at most 5 tests in the vicinity of the changed method (look for some appropriate senders) What we got for this: 1. TDD really beautiful. Accept a test method -> debugger pops up -> write the code in the debugger -> restart -> rinse and repeat. 2. Lint complained instantly. Very useful. As and when. 3. Change domain code: breaking test pops up -> edit code in the debugger! Problems we had: 1. Monkey patching OmniBrowser to do stuff when accepting a method. Work to figure out how in Nautilus :-( 2. Lint became slow. Lots of work to optimise and perhaps exclude some. 3. The responsiveness on accepting a method was just a slight bit slow which put people off 4. Editing in the debugger and lists of methods: no refactoring, no auto-formatting; pain Solutions: 1. Make it run in the background (continuously). Protect from running too often. 2. Get the method list browser and debugger editors to behave the same as Nautilus (at a method level) 3. Record information about failing tests, and run the ones that tend to fail more often 4. Use changes to help with "run tests for stuff that I am working on"
