Re: [FR-devel] Unit Testing integration (was: Re: Welcome to FR-devel)

[NISHIO Mizuho]

At Thu, 2 May 2002 12:46:10 +0200,
Baptiste Lepilleur wrote:
> 
> You're welcome. Here is what I have in my head concerning Unit Testing
> integration (I'm taking test/unit as a reference since it also support
> RUnit):
> 
> The user should be able to run the unit tests of a specific file (it may be
> a single test case or a test suite (a file that require other test case).
> 
> The IDE should collect test failures and statistics (how many tests,
> failures...)
> 
> A failure should have the following information:
> - failed fixture/test names
> - assertion location: filename/line
> - short description: 'actual value is different from the expect value'
> - long description:
>     '-Expected:    3125789'
>     '-Actual:        3125689'
> - backtrace: location of the callers, should be filtered so that it does not
> contains test/unit and FreeRIDE callers.
Though I don't know the detail of Test::Unit, 
Test::Unit supports these things, except the last one. 
The thing we must do is to collect these information from Test::Unit.
 
> Once the IDE has the failure it can do many things:
> - set marker in the Scintilla Edit Control to show failures and/or caller
> location, and track them as the code is edited (markers can be made
> invisible if needed).
> - output text in the console window with some colorizations to help diagnose
> failure (emphase the test name and short description for example)
> 
> That interface could easily be started now, we can always give it its
> definitive shape when we know more about Plug-in/Gui (ruby is really
> flexible in that aspect).
Test::Unit has Test::Unit::UI::TestRunnerMediator.
By this, we can easily develop the interface.
For example, Test::Unit::UI::Console, Test::Unit::UI::FOX 
and Test::Unit::UI::Gtk(these are included in Test::Unit)
uese the object of this class.
 
> We could start by running the unit test in the same process as the IDE, then
> later running them in another process for safety. For example, I stumbled on
> a bug in ruby extension API which caused the garbage collection to blew up.
> We don't want to have the IDE crash later on because of things like this.
> But since it is a seldom case, we don't need that for the first version. It
> shouldn't have any impacts on the interface anyway.
RubyWin executes the Ruby script in the same process of IDE.
This makes some problems.

So, I think that running the unit test in another process is important
(and the debugger should run in another process, too).
It is easy to communicate with the Ruby Object of 
another process by using dRuby though I am not sure that dRuby 
works well in mswin32 Ruby.

Does anyone try to develop Test::Unit::UI::dRuby?

***********************
NISHIO Mizuho
e-mail : address@hidden