Unit Testing Interface
Test plans can be global (Tools|Test Plans|Create New Global Test Plan... or project-specific (right-click on a project and select Create New Test Plan...).
- Give the test plan a useful name
- Select the language
- Set the directory to run the test command in (usually the base directory
of a project). - Specify any additional command line options (see below).
- Click 'OK' to save the test plan
To run the test plan, select it from the drop list in the Project
Unit Tests Results tab.
The Project drop list shows a list of open projects containing test plans and a [top level] item for global test plans. The Test Plan drop list shows the test plans for the selected project.
Supported Frameworks by Language
- Perl: Uses 'make test'. If no Makefile is
present, it first runs 'perl Makefile.PL' to generate one before
running 'make test'. - Python: Uses the unittest framework. You
need to specify a list of files and/or directories to test. - PHP: Uses the PHPUnit framework. Set the
test plan to point to the base directory of the project. The test harness will
look for a subdirectory called tests. - Ruby: Runs 'rake'. If the default action of
the Rakefile is to run tests, no command-line options are needed. If not,
enter the appropriate target for rake (e.g. 'rake test').
For Ruby, you have the unit tests defined by running "rake" and having the user specify the rest of the command line. If that's *all* it does, then it seems to me that it's only a shorthand for building a command widget to run Rake. The only difference is that in a unit test, I don't have to type the first word of the command line when I set it up, just the rest of it. Moreover, the way it's done now, I'm limited to using "rake" to run my tests.
What I think would be more convenient would be to either add an extra field to the dialog box for the user to select the test initiation command, or having the user specify the whole command line in the command line entry field you have now. That way, I could start my tests with "spec specs.rb", which is the way I normally do unit tests.
For the alpha we're supporting one type of test harness for
each of the four languages listed above. The next step will be
to add support for more harnesses (and possibly more languages).
For Ruby the next step will most likely support running of
arbitrary tests based on Test::Unit, similar to the current
support for Python tests.
Ruby has a very active set of developers that focus mostly on testing tools, behavior- and test-driven development. I can name some packages: rspec, heckle, flog, zentest, selenium, cerberus and rcov just popped into my head with little thought. I suspect the most commonly used test-driven development tool at the moment is still Test::Unit, but rspec is gaining ground quickly.
I think rake is the right "first step". It's the Ruby equivalent of Java's "ant" and Python's "scons". But that's really what it is -- a *build* tool, not a testing tool. The ones I listed above are the testing tools.
Speaking of new features migrating out of the generic command tool, one of the things I find myself wanting is the ability to associate a file type with an editor *other* than Komodo. For example, a lot of my projects have documents edited with the LyX LaTeX editor. Right now, for example, I have a little command box in the project that I can double-click on to open a specific document in LyX. I suppose I could go find the LyX icon and replace the little terminal symbol with it, and no one would be the wiser. :)
That would include Module::Build, but most of the CPAN modules I sampled
still use MakeMaker.
The kind of output that Devel::Cover generates doesn't fit as well
in the Komodo Test Plan Results window. However, ActiveState
does have a nice solution for pulling graphical information out
of Devel::Cover runs with version 7.1 of the Perl Dev Kit.
See http://www.activestate.com/Products/perl_dev_kit/fix.mhtml
for more information.
I see that the tests for a Perl project will be run by using the "make test" invocation.
As Windows users normally use the "nmake.exe" utility (which may or may not be in the PATH Windows looks at to find it), could you perhaps consider adding the possibility to choose the "make/nmake" utility to be used?
CountZero
On non-Windows platforms, it assumes make is called "make".
If it finds one in the path, it uses it. Otherwise it
doesn't run the tests.
On Windows, it first checks the path, but if no "nmake.exe"
is found that way, it looks in the registry for the location
of a Visual Studio installation, and finds nmake.exe that
way.
Note that if you're testing an XS library, and nmake wants
to rebuild part of it, you need to have the Visual C++
environment loaded when Komodo is launched.
The Ruby test harness is actually a Test::Unit harness, but given our time
frame, and that I had only one place to locate it, it made more sense to
position it within Rake, instead of using it standalone.
Live I've been saying here, more harnesses will be on their way.