I've worked on hardware logic design, where the time and effort required to create good tests that find subtle bugs rivals the complexity of the hardware being designed itself. In this context, much of the testing has often been generated using pseudo-random streams similar to test.generative and the simulation approach being advocated for software. I think that is a great idea for improving software quality.
In hardware testing via simulation, reproducible tests are important because most of the testing cycles are run with a low amount of logging enabled -- just enough logging to look for signs of incorrect behavior. When a hardware designer wants to debug the problem, the test can be re-run with very detailed logs enabled (basically amounting to recording the logic 0/1 value of every wire in the hardware being designed at every instant in simulated time). These are much slower and require a lot more temporary disk space to record the logs. So you end up using a large variety of different seed values to increase test coverage, and if any of them fails, you can turn on the extra logging and re-run it, knowing that you will hit the same problem as before. Andy On Thu, Jun 6, 2013 at 12:30 PM, Chas Emerick <c...@cemerick.com> wrote: > Well, if *that's* all it is, I'll feel like quite the heel for putting so > much thought into it! ;-) > > Assuming failures are rarer, then starting with a just-previously-failed > seed would be better as an explicit action, rather than defaulting to a > constant? > > - Chas > > On Jun 6, 2013, at 3:21 PM, Raoul Duke wrote: > > > i always thought it was basically solely for letting you re-run the > > test that just/previously failed, nothing more weird or silly than > > that. > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
