On 12/01/2015 09:40 AM, Simon Glass wrote:
...
At present we don't have a sensible test framework for anything other
than sandbox, so to me the main benefit is that with your setup, we
do.
The benefit of the existing sandbox tests is that they are very fast.
We could bisect for a test failure in a few minutes. I'd like to make
sure that we can still write C tests (that are called from your
framework with results integrated into it) and that the Python tests
are also fast.
How do we move this forward? Are you planing to resend the patch with
the faster approach?
I'm tempted to squash down all/most the fixes/enhancements I've made
since posting the original into a single commit rather than sending
follow-on enhancements, since none of it is applied yet. I can keep the
various test implementations etc. in separate commits as a series. Does
that seem reasonable?
I need to do some more testing/clean-up of the version that doesn't use
pexpect. For example, I have only tested sandbox and not real HW, and
also haven't tested (and perhaps implemented some of) the support for
matching unexpected error messages in the console log. Still, that all
shouldn't take too long.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
