1. 15 Feb, 2016 3 commits
  2. 09 Feb, 2016 1 commit
    • Stephen Warren's avatar
      test/py: HTML awesome! · 83357fd5
      Stephen Warren authored
      Implement three improvements to the HTML log file:
      - Ability to expand/contract sections. All passing sections are contracted
        at file load time so the user can concentrate on issues requiring
        action.
      - The overall status report is copied to the top of the log for easy
        access.
      - Add links from the status report to the test logs, for easy navigation.
      
      This all relies on Javascript and the jquery library. If the user doesn't
      have Javascript enabled, or jquery can't be downloaded, the log should
      look and behave identically to how it did before this patch.
      
      A few notes on the diff:
      
      - A few more 'with log.section("xxx")' were added, so that all stream
        blocks are kept within a section block for consistent HTML entity
        nesting structure. This changed indentation in a few places, making
        the diff look slightly larger.
      - HTML entity IDs are cleaned up. We assign simple incrementing integer
        IDs now, rather than using mangled test names which were possibly
        invalid.
      - Sections and streams now use common CSS class names (in addition to the
        current separate class names) to more easily share the new behaviour.
        This also reduces the CSS file size since rules don't need to be
        duplicated.
      - An "OK" status is logged after some external command executions so that
        make and flash steps are auto-contracted at log file load time, assuming
        they passed.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      83357fd5
  3. 08 Feb, 2016 1 commit
    • Stephen Warren's avatar
      test/py: support running sandbox under gdbserver · 89ab8410
      Stephen Warren authored
      Implement command--line option --gdbserver COMM, which does two things:
      
      a) Run the sandbox process under gdbserver, using COMM as gdbserver's
         communication channel.
      
      b) Disables all timeouts, so that if U-Boot is halted under the debugger,
         tests don't fail. If the user gives up in the middle of a debugging
         session, they can simply CTRL-C the test script to abort it.
      
      This allows easy debugging of test failures without having to manually
      re-create the failure conditions. Usage is:
      
      Window 1:
      ./test/py/test.py --bd sandbox --gdbserver localhost:1234
      
      Window 2:
      gdb ./build-sandbox/u-boot -ex 'target remote localhost:1234'
      
      When using this option, it likely makes sense to use pytest's -k option
      to limit the set of tests that are executed.
      
      Simply running U-Boot directly under gdb (rather than gdbserver) was
      also considered. However, this was rejected because:
      
      a) gdb's output would then be processed by the test script, and likely
         confuse it causing false failures.
      
      b) pytest by default hides stdout from tests, which would prevent the
         user from interacting with gdb.
      
         While gdb can be told to redirect the debugee's stdio to a separate
         PTY, this would appear to leave gdb's stdio directed at the test
         scripts and the debugee's stdio directed elsewhere, which is the
         opposite of the desired effect. Perhaps some complicated PTY muxing
         and process hierarchy could invert this. However, the current scheme
         is simple to implement and use, so it doesn't seem worth complicating
         matters.
      
      c) Using gdbserver allows arbitrary debuggers to be used, even those with
         a GUI. If the test scripts invoked the debugger themselves, they'd have
         to know how to execute arbitary applications. While the user could hide
         this all in a wrapper script, this feels like extra complication.
      
      An interesting future idea might be a --gdb-screen option, which could
      spawn both U-Boot and gdb separately, and spawn the screen into a newly
      created window under screen. Similar options could be envisaged for
      creating a new xterm/... too.
      
      --gdbserver  currently only supports sandbox, and not real hardware.
      That's primarily because the test hooks are responsible for all aspects of
      hardware control, so there's nothing for the test scripts themselves can
      do to enable gdbserver on real hardware. We might consider introducing a
      separate --disable-timeouts option to support use of debuggers on real
      hardware, and having --gdbserver imply that option.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      89ab8410
  4. 29 Jan, 2016 5 commits
    • Stephen Warren's avatar
      test/py: correctly log xfail/xpass tests · 78b39cc3
      Stephen Warren authored
      Tests can complete in passed, skipped, xpass, xfailed, or failed, states.
      Currently the U-Boot log generation code doesn't handle the xfailed or
      xpass states since they aren't used. Add support for the remaining states.
      Without this, tests that xfail end up being reported as skipped.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      78b39cc3
    • Stephen Warren's avatar
      test/py: Provide custom IDs when parametrizing tests · d20e5e97
      Stephen Warren authored
      When pytest generates the name for parametrized tests, simple parameter
      values (ints, strings) get used directly, but more complex values such
      as dicts are not handled. This yields test names such as:
      
          dfu[env__usb_dev_port0-env__dfu_config0]
          dfu[env__usb_dev_port0-env__dfu_config1]
      
      Add some code to extract a custom fixture ID from the fixture values, so
      that we end up with meaningful names such as:
      
          dfu[micro_b-emmc]
          dfu[devport2-ram]
      
      If the boardenv file doesn't define custom names, the code falls back to
      the old algorithm.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      d20e5e97
    • Stephen Warren's avatar
      test/py: use " for docstrings · e8debf39
      Stephen Warren authored
      Python's coding style docs indicate to use " not ' for docstrings.
      
      test/py has other violations of the coding style docs, since the docs
      specify a stranger style than I would expect, but nobody has complained
      about those yet:-)
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      e8debf39
    • Stephen Warren's avatar
      test/py: drain console log at the end of any failed test · c10eb9d3
      Stephen Warren authored
      Tests may fail for a number of reasons, and in particular for reasons
      other than a timeout waiting for U-Boot to print expected data. If the
      last operation that a failed test performs is not waiting for U-Boot to
      print something, then any trailing output from U-Boot during that test's
      operation will not be logged as part of that test, but rather either
      along with the next test, or even thrown away, potentiall hiding clues
      re: the test failure reason.
      
      Solve this by explicitly draining (and hence logging) the U-Boot output
      in the case of failed tests.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      c10eb9d3
    • Stephen Warren's avatar
      test/py: move U-Boot respawn trigger to the test core · 636f38d8
      Stephen Warren authored
      Prior to this change, U-Boot was lazilly (re-)spawned if/when a test
      attempted to interact with it, and no active connection existed. This
      approach was simple, yet had the disadvantage that U-Boot might be
      spawned in the middle of a test function, e.g. after the test had already
      performed actions such as creating data files, etc. In that case, this
      could cause the log to contain the sequence (1) some test logs, (2)
      U-Boot's boot process, (3) the rest of that test's logs. This isn't
      optimally readable. This issue will affect the upcoming DFU and enhanced
      UMS tests.
      
      This change converts u_boot_console to be a function-scoped fixture, so
      that pytest attempts to re-create the object for each test invocation.
      This allows the fixture factory function to ensure that U-Boot is spawned
      prior to every test. In practice, the same object is returned each time
      so there is essentially no additional overhead due to this change.
      
      This allows us to remove:
      
      - The explicit ensure_spawned() call from test_sleep, since the core now
      ensures that the spawn happens before the test code is executed.
      
      - The laxy calls to ensure_spawned() in the u_boot_console_*
      implementations.
      
      The one downside is that test_env's "state_ttest_env" fixture must be
      converted to a function-scoped fixture too, since a module-scoped fixture
      cannot use a function-scoped fixture. To avoid overhead, we use the same
      trick of returning the same object each time.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      636f38d8
  5. 21 Jan, 2016 1 commit
    • Stephen Warren's avatar
      test/py: Implement pytest infrastructure · d201506c
      Stephen Warren authored
      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!
      Signed-off-by: default avatarStephen Warren <swarren@wwwdotorg.org>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Tested-by: default avatarMichal Simek <michal.simek@xilinx.com>
      Tested-by: default avatarSimon Glass <sjg@chromium.org>
      Acked-by: Simon Glass <sjg@chromium.org> #v3
      d201506c