From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Mon, 11 Jan 2016 10:04:44 -0700 Subject: [U-Boot] [PATCH V3 1/7] test/py: Implement pytest infrastructure In-Reply-To: References: <1452034715-26166-1-git-send-email-swarren@wwwdotorg.org> <568FFC30.5000501@wwwdotorg.org> <569000AF.6080002@monstr.eu> Message-ID: <5693E0AC.4030903@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 01/11/2016 08:25 AM, Simon Glass wrote: > Hi Stephen, > > On 8 January 2016 at 11:32, Michal Simek wrote: >> >> On 8.1.2016 19:13, Stephen Warren wrote: >>> On 01/05/2016 03:58 PM, Stephen Warren wrote: >>>> This tool aims to test U-Boot by executing U-Boot shell commands using >>>> the >>>> console interface. A single top-level script exists to execute or attach >>>> to the U-Boot console, run the entire script of tests against it, and >>>> summarize the results. Advantages of this approach are: >>>> >>>> - Testing is performed in the same way a user or script would interact >>>> with U-Boot; there can be no disconnect. >>>> - There is no need to write or embed test-related code into U-Boot >>>> itself. >>>> It is asserted that writing test-related code in Python is simpler and >>>> more flexible that writing it all in C. >>>> - It is reasonably simple to interact with U-Boot in this way. >>>> >>>> A few simple tests are provided as examples. Soon, we should convert as >>>> many as possible of the other tests in test/* and test/cmd_ut.c too. >>>> >>>> The hook scripts, relay control utilities, and udev rules I use for my >>>> own HW setup are published at >>>> https://github.com/swarren/uboot-test-hooks. >>>> >>>> See README.md for more details! >>> >>> It looks like I need to send a v4 of this, since I renamed a Python >>> class but forgot to update all users of it. I didn't notice this, since >>> I had the old module lying around as a *.pyc file, so the old name >>> worked:-( >>> >>> I also have a couple of minor fixes to roll in that make the scripts >>> work better under a continuous integration environment (which doesn't >>> have a controlling TTY set when the scripts run, which need a minor >>> tweak to the Spawn code). > > I see this now. Do I need another dependency? > > /test/py/test.py --bd sandbox --build ... > INTERNALERROR> from ubspawn import Spawn No, I renamed the ubspawn class (to u_boot_spawn) but forgot to update the users of the module to use the new name. My local testing didn't notice this since I still had the .pyc file present with the old name, but you evidently don't. I think something like the following should fix it for you before I post v4: sed -i 's/ubspawn/u_boot_spawn/' test/py/*.py