From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 1 Dec 2015 16:24:42 -0700 Subject: [U-Boot] [PATCH] Implement pytest-based test infrastructure In-Reply-To: References: <1447570381-1361-1-git-send-email-swarren@wwwdotorg.org> <564E0030.9090808@wwwdotorg.org> <564E1E6B.7010708@wwwdotorg.org> <5651FBB0.9010202@wwwdotorg.org> <5653EB13.60506@wwwdotorg.org> <5654D67B.2090307@wwwdotorg.org> <565C83B3.5090706@wwwdotorg.org> Message-ID: <565E2C3A.6020900@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.