Difference between revisions of "Testing Inkscape"

From Inkscape Wiki
Jump to navigation Jump to search
m (link fix)
 
(Refactored page to add a section on Unit testing)
Line 1: Line 1:
== Inkscape Testing ==
== Testing Inkscape ==


Developers and users do a fair job of basic testing of Inkscape in regular use; the inkscape-tester community focuses on advanced testing including:
Inkscape is a young project and the emphasis is still on adding features. Nonetheless is is gratifying that the stability of Inkspace has been steadily rising with each release.
 
The most important part of 'Testing' is simply to use Inkscape for [[FAQ#Is_Inkscape_ready_for_regular_users_to_use.3F|normal work]] -- confirming that Inkscape has reached this level of maturity, exercise the new features and verify that the application works as expected.
 
? Bug reports<br>
? Follow up
 
=== Developers ===
 
There are now some UnitTests which should be performed before checking in. These may take over 2 minutes to complete, and so this cannot be made a requirement for each build (Test Driven Development), nonetheless everyone is on their honour not to 'break the build' by committing code that does not pass these tests.
 
There is an 'inkscape build report; which is sent regularly to the inkscape-tester list (and periodically to the developer list, when new problems are seen) that gives a count of warnings spotted in the code.
 
* Smoketests
* Defects in the build system
 
=== Users ===
 
The field is wide open. We are keen to receive [http://sourceforge.net/tracker/?group_id=93438&atid=604306 bug reports] and [http://sourceforge.net/tracker/?group_id=93438&atid=604309 feature requests]. These often require analysis, clarification and further action. Anyone can do this. Better still would be to provide patches for any part of the application that is not up to the standard you expect - it is confirmation that the project is evolving. Note that serious testing should be done with an 'unstable' build, either one that you made yourself (to be fair building Inkscape requires gathering many libraries and will take a fair bit of time - it is not a 'good project' for your first foray into source code), or a snapshot that you have downloaded. We would also like to hear about areas in which we do not have parity with comparable applications. If you find that you are coming up with interesting ideas concerning shortcomings in Inkscape, or plans for its future, get involved with the Inkscape testers group.
 
We need people to create and update documentation, online help, tutorials and screen shots. Noting defects in these is a perfectly valid form of testing - we do not want releases to go out with obsolete documentation.
 
=== Inkscape Testers ===
 
A community of Inkscape testers has grown up which has its own  [http://lists.sourceforge.net/lists/listinfo/inkscape-tester mailing list], and it is to be hoped that this will spearhead all work on usability and human factors. This group should be your first port of call for these areas:


* [[ComplianceTesting]]
* [[ComplianceTesting]]
Line 8: Line 32:
* [[UsabilityTesting]]
* [[UsabilityTesting]]
* [[PerformanceTesting]]
* [[PerformanceTesting]]
* HIG compliance


The Inkscape Testers community has a <a href="http://lists.sourceforge.net/lists/listinfo/inkscape-tester">mailing list</a> dedicated to the testing of Inkscape
See also [[TestingFramework]].


See also [[TestingFramework]]
Note: Bryce? Jon? shouldn't the whole of that page be merged here? Or is it better to have this info in two pieces. IMHO wiki pages should not be made too long.

Revision as of 22:49, 7 May 2006

Testing Inkscape

Inkscape is a young project and the emphasis is still on adding features. Nonetheless is is gratifying that the stability of Inkspace has been steadily rising with each release.

The most important part of 'Testing' is simply to use Inkscape for normal work -- confirming that Inkscape has reached this level of maturity, exercise the new features and verify that the application works as expected.

? Bug reports
? Follow up

Developers

There are now some UnitTests which should be performed before checking in. These may take over 2 minutes to complete, and so this cannot be made a requirement for each build (Test Driven Development), nonetheless everyone is on their honour not to 'break the build' by committing code that does not pass these tests.

There is an 'inkscape build report; which is sent regularly to the inkscape-tester list (and periodically to the developer list, when new problems are seen) that gives a count of warnings spotted in the code.

  • Smoketests
  • Defects in the build system

Users

The field is wide open. We are keen to receive bug reports and feature requests. These often require analysis, clarification and further action. Anyone can do this. Better still would be to provide patches for any part of the application that is not up to the standard you expect - it is confirmation that the project is evolving. Note that serious testing should be done with an 'unstable' build, either one that you made yourself (to be fair building Inkscape requires gathering many libraries and will take a fair bit of time - it is not a 'good project' for your first foray into source code), or a snapshot that you have downloaded. We would also like to hear about areas in which we do not have parity with comparable applications. If you find that you are coming up with interesting ideas concerning shortcomings in Inkscape, or plans for its future, get involved with the Inkscape testers group.

We need people to create and update documentation, online help, tutorials and screen shots. Noting defects in these is a perfectly valid form of testing - we do not want releases to go out with obsolete documentation.

Inkscape Testers

A community of Inkscape testers has grown up which has its own mailing list, and it is to be hoped that this will spearhead all work on usability and human factors. This group should be your first port of call for these areas:


See also TestingFramework.

Note: Bryce? Jon? shouldn't the whole of that page be merged here? Or is it better to have this info in two pieces. IMHO wiki pages should not be made too long.