Re: [libredwg] Testing suite samples

[guruprasad rane]

I am not very clear about the features that will be tested. I presume that we will test the READING and WRITING of dwg, dxf files.

I have uploaded a sample archive file "sample.zip". http://ia341310.us.archive.org/3/items/LibredwgTestSuite0.1/  It has 001-circle.dwg and 001-circle-properties.csv.


001-circle.dwg is a drawing file for testing. It has just one circle in it.

001-circle-properties.csv has the list of properties of the circle in it in human readable format.

The test suite can read the drawing file and get the properties of circle. Then it can read the csv file and check whether the values are same. If it is same then the READING TEST for CIRCLE is passed. Then let it go to writing test. Write a temp file with circle with same properties as that of circle in 001-circle.dwg. Then again read the temp file and compare with properties in 001-circle-properties.csv. If it is same then the WRITING TEST for CIRCLE is passed.


Like this we can go on adding new files with all versions for every objects. At later stage we can add files with multiple objects and more complex files.

The files can be created from scratch using AUTOCAD so that they can be released on public domain.

Regards
Guruprasad

2010/1/20 Rodrigo Rodrigues da Silva <address@hidden>

Guruprasad Rane wrote:

I propose that we make DWG files using AUTOCAD with native DWG elements
like Line.dwg, polyline.dwg, circle.dwg, and so on. If this approach is
correct, I can start creating these files.
 

I agree. I'd say a few things:

* Files must be released to the public domain (preferably created by ourselves or third party if already public domain)
* Fileset should cover all versions supported by LibreDWG: R13, R14, R2000 (R15), R2004 (R16), R2007 (R17). If possible, R2010 (R18), since we might support it in the future.
* Increasing levels of complexity (files within each level may also have different levels of complexity, regarding the number of entities or file size):
** Basic: mandatory entities and objects, that every (2D?) converter would need
** Intermediate: more sophisticated, but still useful entities and objects (maybe put 3D entities here? or create a separate level?)
** Advanced: all remaining objects and entities (at least the documented/default ones)
** Unsupported: objects not supported by LibreDWG.

The test suite result would be a cube, consisting of:
x axis: complexity levels; y axis: version ; z axis: % of files that passed the text

or:
x: file; y: version; z: entities and objects covered by the test (% spec coverage)

We should ideally have a summary telling us if one entity or object has or has not been tested (I can't say if we've ever decoded a IDBUFFER object) throughout the samples.

What "passed" means? Initially, if load_dwg (or any other executable) doesn't segfault while parsing the file. We could have a fine grained error checking, though. We need to make sure (maybe that'll turn to be impossible) that our samples go through every possible path along the decoder code (many entity/decode objects have if's and switch's).

Before we start creating the files, we should distribute the DWG objects among the categories, and create files with those categories in mind.

I'll setup a LibreDWG/TestSuite wiki page with this proposal (and possilbly other stuff discussed along this thread) if you agree with it.

Regards
Guruprasad

On Tue, 2010-01-19 at 17:00 -0200, Rodrigo Rodrigues da Silva wrote:
 

It just came to my mind that maybe we're taking the wrong approach building these samples. My point is: a dwg file created by a
converter and from an SVG file will be limited to the subset of entities and objects supported by the converter. Besides, an SVG file carries less information than a DWG file (we'll never get any DIMENSION, MESH or 3DSOLID entities or an OLE2_CONTROL object from a SVG2DWG converter).

That doesn't mean they're not useful, we can still test most of the common 2D entities and run performance tests.

I've got a couple of R2004 files that I can release to the public domain. Althoug, they are fairly simple and wouldn't cover all the objects and entities, not even common ones like dimensions.