define tests

[el-j]

we need to define the automatic test when a pull request is send.
with the new fritzing version 0.9.3b and the git-parts-magic people
really begin to contribute parts via git.

therefore the main issues are:
fzp check:

• properties: family
• unique module id
• all connectors in all views defined
• check if all connectors has names #16 all connectors has names

breadboardview:

• linked imagefiles? (we just use pure svgs)

schematicview:

• linked imagefiles?

pcb-view:

• if Through-hole part (tht):
  • missing one cooper layer?
  • is copper1 in copper0
  • connectors need to be "circle" svg elements
• if smd:
  • just one cooper0 group
  • connectors cannot be "circle" svg elements
  • connector elemtents need a stroke-width="0" and stroke="none"

[paulvollmer]

@el-j can you write some comments to the go Check funcs...
for example the "all connectors has names" issue goes to the https://github.com/paulvollmer/fzp/blob/master/src/go/connector.go#L26 file.
so, i can start implementing the checks and write the tests.

[paulvollmer]

and please create for each check we need to write a single issue.
for better overview...

[paulvollmer]

@KjellMorgenstern here some notes about the planned features for the validator.
i'm not sure how much bugs at the fzp files the validator catch. we should start at this repository and write tests of invalid xml code to make the validator better.

what do you think?

[KjellMorgenstern]

I think we can straight forward open 12 single issues, one for each proposed check.

Automated checks are much more valuable if we have a simple "green" / "red" flag, it doesn't make sense if the nighly is always red because there are a few old parts without proper images.
For each check, if we enable the check, we have to immediately fix all reported parts ourselfes, or remove them.