We need to generate two types of reports.
The first set will be created by taking a set of often-used applications on each Ubuntu release, running them in a chroot, and sending SIGSEGV to them after some time. These can be packaged up and live in the branch responsible for testing the error tracker. We'll test that these always generate a complete stacktrace and are inserted into the database in the correct manner. If we want to test that multiple instances of these crashes increment the counter for their respective bucket, we'll have to just send them twice, since there's no way of predicting what function the program will be in at the time of crash.
We'll generate a second type of crash to test that different StacktraceAddressSignatures for the same resulting stacktrace get bucketed together, and that the crash signature always looks the same given a StacktraceAddressSignature. These reports will be generated by creating a new package of binaries that cause a signal that drops a core file. This package will be published in a PPA [1] with armhr and ddeb support and included in the production retracer configuration. This means that we can not only test these in our local unit tests against development branches, but also against production using Nagios at regular intervals. It also makes it easy to filter these out of statistics, since we can key against a testing package name.
1: https://launchpad.net/~daisy-pluckers/+archive/daisy-seeds
Another possibility is to generate the "well known programs" .crash files during package build and ship them in the debs in the PPA. That way it is very easy to generate them on all supported architectures for multiple releases. So the "daisy-test" source package would then ship one .deb with the pregenerated .crash files, and another with the /usr/bin/crash binary which crashes in multiple different ways, depending on CLI arguments or environment variables. The latter would then have an automatically generated .ddeb in the PPA as well.