> I knew you'd raise this point ;-) > > My reasoning is that, for a testcase, the "results" are the testcases > pass/fail results themselves. And stdout is usually used for 'results'. > > So was wanting to use stdout only for BEGIN, SKIP, PASS and FAIL > messages. If we need additional debugging (hex dumps, warning or > informational messages etc), we would send them through stderr.
I don't think just sending informational messages,etc through stderr will help that much, unless we know which test specifically failed (or was running), too... For now our testsuite is small enough that its easy to figure out, but that may change... > But changing that is simple ;-) What do you think? Basically my thought is that stdout and stderr by default go to the same place, but if we don't send some stuff to stderr then we lose the ability to "split" the streams if we choose to when running the tests. Since there may be some times want to send stderr elsewhere, its better to have that option than to not. Let me know what you think... Thanks, Kent > -Klaus > ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Opencryptoki-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opencryptoki-tech
