Hi otto
we really want that the infrastructure of Pharo tools lets you define
such process.
So this is important that you
- notify us
- potentially contribute with code.
Remember pharo is not just an external tool, this is your system.
Le 21/4/15 18:29, Otto Behrens a écrit :
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)
Now we should have that. I always wanted to have that :)
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)
Cool :)
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!
:)
It would be really nice to have a package with a setup like that.
The tools should be open and customizable for such process.
If you want to push this we will really help.
Problems we had:
1. Monkey patching OmniBrowser to do stuff when accepting a method.
Work to figure out how in Nautilus :-(
We should do a pass on nautilus but normally there should be an
event for that.
2. Lint became slow. Lots of work to optimise and perhaps exclude some.
We have false positive support and we can filter the rules. So with
the work on uko if should be getting better and better.
3. The responsiveness on accepting a method was just a slight bit slow
which put people off
did you check recently because we did some bench like running all
the rules on a method and it was under a second.
4. Editing in the debugger and lists of methods: no refactoring, no
auto-formatting; pain
We started to add refactorings in all the senders/implementors and
others.
Now if you see a place where there are missing, again send us the
code.
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"
