TestSuite-blueprint - Revision history

Mgmax: Replaced content with "removed - outdated Category:Proposals"

2025-05-26T14:46:03Z

Replaced content with "removed - outdated Category:Proposals"

Romain2Boss: Add category Proposals

2012-03-31T10:35:32Z

Add category Proposals

← Older revision		Revision as of 10:35, 31 March 2012
Line 318:		Line 318:

	Note that I have ignored livarot (and third-party libraries, including 2geom) entirely.		Note that I have ignored livarot (and third-party libraries, including 2geom) entirely.

			[[Category:Proposals]]

Jaspervdg: /* Future work */

2008-11-14T07:54:41Z

Future work

← Older revision		Revision as of 07:54, 14 November 2008
Line 297:		Line 297:
	* color.cpp		* color.cpp
	* conditions.cpp		* conditions.cpp
	* inkscape.cpp (specifically inkscape_get_repr)		* inkscape.cpp (specifically inkscape_get_repr), update: "replaced by either Inkscape::Preferences, or Inkscape::Preferences::Observer" (thanks tweenk)
	* sp-image.cpp		* sp-image.cpp
	* sp-*		* sp-*

Jaspervdg: For requests, please use the bug tracker, don't just change the results of this GSoC project. Undo revision 37794 by Tweenk (Talk)

2008-11-11T09:05:48Z

For requests, please use the bug tracker, don't just change the results of this GSoC project. Undo revision 37794 by Tweenk (Talk)

← Older revision		Revision as of 09:05, 11 November 2008
Line 297:		Line 297:
	* color.cpp		* color.cpp
	* conditions.cpp		* conditions.cpp
	* ~~preferences~~.cpp		* inkscape.cpp (specifically inkscape_get_repr)
	* sp-image.cpp		* sp-image.cpp
	* sp-*		* sp-*

Tweenk: /* Future work */

2008-11-07T23:49:48Z

Future work

← Older revision		Revision as of 23:49, 7 November 2008
Line 297:		Line 297:
	* color.cpp		* color.cpp
	* conditions.cpp		* conditions.cpp
	* ~~inkscape~~.cpp ~~(specifically inkscape_get_repr)~~		* preferences.cpp
	* sp-image.cpp		* sp-image.cpp
	* sp-*		* sp-*

Jaspervdg: /* Rough prioritization */

2008-08-16T11:50:33Z

Rough prioritization

← Older revision		Revision as of 11:50, 16 August 2008
Line 264:		Line 264:
	* Identify interesting areas of the code for creating further unit tests.		* Identify interesting areas of the code for creating further unit tests.
	** (sent mail) Discuss problem areas in the code with the Inkscape community.		** (sent mail) Discuss problem areas in the code with the Inkscape community.
	** Use SVN logs to identify often edited, very new and very old code.		** (done) Use SVN logs to identify often edited, very new and very old code.
	** Use gcov to determine what parts of the code are executed very often and which are executed hardly ever.		** (done) Use gcov to determine what parts of the code are executed very often and which are executed hardly ever.

	== Future work ==		== Future work ==

Jaspervdg: /* Future work */

2008-08-16T10:58:27Z

Future work

← Older revision		Revision as of 10:58, 16 August 2008
Line 312:		Line 312:

	I also looked at the least executed parts of the codebase, but that's much trickier (there is much more "noise" in the form of files that contain some trivial line of code that is executed once or twice), so I decided not to draw any conclusions from that.		I also looked at the least executed parts of the codebase, but that's much trickier (there is much more "noise" in the form of files that contain some trivial line of code that is executed once or twice), so I decided not to draw any conclusions from that.

			Something similar holds for SVN logs. I had a look at the most and least recently updated files, but there was way too much (not very discriminating) data to make a useful statement. But it might give a nice guideline if you want to prioritize creation of a predetermined set of tests. In any case, a small tool can be found in SVN ([http://inkscape.svn.sourceforge.net/svnroot/inkscape/gsoc-testsuite/analysis/activity.py activity.py]) that can read XML formatted SVN logs and output a list of touched files, sorted by their last action date.

	Finally, I have focussed mainly on rendering as it is relatively easy to test and quite critical, but it would be good to look at more aspects of Inkscape in the future. Verb tests could help here, but more direct UI testing would also be good, as would testing of Inkscape's export functionality, effects, etc.		Finally, I have focussed mainly on rendering as it is relatively easy to test and quite critical, but it would be good to look at more aspects of Inkscape in the future. Verb tests could help here, but more direct UI testing would also be good, as would testing of Inkscape's export functionality, effects, etc.

	Note that I have ignored livarot (and third-party libraries, including 2geom) entirely.		Note that I have ignored livarot (and third-party libraries, including 2geom) entirely.

Jaspervdg: /* Future work */

2008-08-15T15:19:18Z

Future work

← Older revision		Revision as of 15:19, 15 August 2008
Line 310:		Line 310:
	* libnr/*		* libnr/*
	* xml/*		* xml/*

			I also looked at the least executed parts of the codebase, but that's much trickier (there is much more "noise" in the form of files that contain some trivial line of code that is executed once or twice), so I decided not to draw any conclusions from that.

	Finally, I have focussed mainly on rendering as it is relatively easy to test and quite critical, but it would be good to look at more aspects of Inkscape in the future. Verb tests could help here, but more direct UI testing would also be good, as would testing of Inkscape's export functionality, effects, etc.		Finally, I have focussed mainly on rendering as it is relatively easy to test and quite critical, but it would be good to look at more aspects of Inkscape in the future. Verb tests could help here, but more direct UI testing would also be good, as would testing of Inkscape's export functionality, effects, etc.

	Note that I have ignored livarot (and third-party libraries, including 2geom) entirely.		Note that I have ignored livarot (and third-party libraries, including 2geom) entirely.

Jaspervdg: /* Future work */

2008-08-15T15:12:04Z

Future work

← Older revision		Revision as of 15:12, 15 August 2008
Line 292:		Line 292:
	* display\curve.cpp: 27% (58/218)		* display\curve.cpp: 27% (58/218)
	* svg\svg-length.h: 100% (6/6)		* svg\svg-length.h: 100% (6/6)

			Also, looking at files with code that is executed very, very often the following (classes of) files would be interesting to write new tests for:

			* color.cpp
			* conditions.cpp
			* inkscape.cpp (specifically inkscape_get_repr)
			* sp-image.cpp
			* sp-*
			* style.*
			* uri.cpp
			* verbs.*
			* display/nr-arena-shape.cpp
			* display/nr-filter-*
			* display/*
			* libnr/nr-compose*
			* libnr/nr-gradient.cpp
			* libnr/*
			* xml/*

	Finally, I have focussed mainly on rendering as it is relatively easy to test and quite critical, but it would be good to look at more aspects of Inkscape in the future. Verb tests could help here, but more direct UI testing would also be good, as would testing of Inkscape's export functionality, effects, etc.		Finally, I have focussed mainly on rendering as it is relatively easy to test and quite critical, but it would be good to look at more aspects of Inkscape in the future. Verb tests could help here, but more direct UI testing would also be good, as would testing of Inkscape's export functionality, effects, etc.

			Note that I have ignored livarot (and third-party libraries, including 2geom) entirely.

Jaspervdg: /* Future work */

2008-08-15T13:53:39Z

Future work

← Older revision		Revision as of 13:53, 15 August 2008
Line 277:		Line 277:
	* Removing the old utest tests: Mostly a janitorial task, editing some Makefiles, removing some files and making sure nothing was broken in the process.		* Removing the old utest tests: Mostly a janitorial task, editing some Makefiles, removing some files and making sure nothing was broken in the process.

	~~TODO~~		In addition, after looking at coverage data for the unit tests and rendering tests there are some unit tested files that still contain (sometimes quite a lot of) code that is executed by the rendering tests but is not tested during the unit tests. This is not desirable, as rendering tests are not meant to test very low level functionality. The following files are affected (part of the output of a 'coverage.py -w test -c ...' run, using coverage data of just the unit tests and the unit ''and'' rendering tests), note that lower coverage values are good in this case:

			* display\bezier-utils.cpp: 1% (2/331)
			* verbs.cpp: 1% (6/863)
			* extract-uri.cpp: 5% (2/39)
			* libnr\nr-compose.cpp: 6% (41/704)
			* libnr\nr-scale.h: 6% (1/16)
			* svg\svg-color.cpp: 7% (14/190)
			* verbs.h: 9% (2/23)
			* sp-style-elem.cpp: 10% (15/156)
			* svg\svg-length.cpp: 12% (34/275)
			* color-profile.cpp: 13% (62/484)
			* libnr\nr-point-fns.h: 19% (5/26)
			* display\curve.cpp: 27% (58/218)
			* svg\svg-length.h: 100% (6/6)

			Finally, I have focussed mainly on rendering as it is relatively easy to test and quite critical, but it would be good to look at more aspects of Inkscape in the future. Verb tests could help here, but more direct UI testing would also be good, as would testing of Inkscape's export functionality, effects, etc.