File:  [NetBSD Developer Wiki] / wikisrc / kyua.mdwn
Revision 1.4: download - view: text, annotated - select for diffs
Sat Sep 1 19:17:30 2012 UTC (7 years, 11 months ago) by jmmv
Branches: MAIN
CVS tags: HEAD
Add some additional content, detailing why Kyua is a third-party project
and explaining the ability to generate HTML directly from the tool.

    1: [[!meta title="Kyua: An introduction for NetBSD users"]]
    2: [[!toc levels=2]]
    3: 
    4: The [Automated Testing Framework](ATF), or ATF for short, is a software
    5: package composed of two parts: the *ATF libraries* and the *ATF tools*.
    6: The ATF libraries provide a toolkit for developers to implement test cases
    7: in a variety of languages: C, C++ and POSIX shell.  The ATF tools provide
    8: the utilities to run such test cases in an automated way and to generate
    9: reports.
   10: 
   11: The ATF tools have some
   12: [design and, particularly, implementation problems](http://mail-index.netbsd.org/atf-devel/2010/11/13/msg000206.html)
   13: that make it hard to add support for highly desired features such as
   14: parallel execution of test cases, unified dashboards covering multiple test
   15: runs ([like this one](http://releng.netbsd.org/test-results.html)), the
   16: ability to run legacy or third-party test programs that do not use the ATF
   17: libraries, and the ability to tune the timeout of test cases.
   18: 
   19: *Kyua's current goal is to reimplement _only_ the ATF tools* while
   20: maintaining backwards compatibility with the tests written with the ATF
   21: libraries (i.e. with the NetBSD test suite).
   22: 
   23: Because Kyua is a replacement of some ATF components, the end goal is to
   24: integrate Kyua into the NetBSD base system (just as ATF is) and remove the
   25: deprecated ATF components.  Removing the deprecated components will allow
   26: us to make the above-mentioned improvements to Kyua, as well as many
   27: others, without having to deal with the obsolete ATF code base.
   28: *Discussing how and when this transition might happen is out of the scope
   29: of this document at the moment.*
   30: 
   31: This page provides instructions on how to use Kyua with the current NetBSD
   32: test suite so that you can experiment with the tool, familiarize yourself
   33: with it and provide feedback early on.
   34: 
   35: # What's in the name?
   36: 
   37: You should really think of Kyua as ATF 2.x.  Then, why isn't it just ATF
   38: 2.x?
   39: 
   40: To be honest, I never liked the ATF name: it was picked for me as part of
   41: the Google Summer of Code 2007 program and I did not think about changing
   42: it at that time.  A year later, I learned that the ATF acronym is severely
   43: overloaded, which makes it hard to find the project on popular search
   44: engines, and has unpopular connotations in specific countries.
   45: 
   46: So, as part of the rewrite, I decided to choose a new name: a name that is
   47: not an acronym and thus can be easily pronounced, and a name that is quite
   48: unique in search results.  The name is Kyua, which is just a play on the
   49: pronounciation of the Q.A. acronym.  Originally, my intention was to
   50: pronounce Kyua as Q.A., but in reality this never happened.  Today, just
   51: read the name as your instinct would: "Kyu-ah".
   52: 
   53: # Why is Kyua a third-party project?
   54: 
   55: Kyua's main consumer is NetBSD.  One could argue that Kyua should be
   56: developed within NetBSD and maintained in the NetBSD source tree.  However,
   57: there is nothing in the Kyua project that inherently depends on NetBSD, and
   58: maintaining it as a third-party package is a way to keep the developers
   59: honest regarding portability.
   60: 
   61: Ideally, other projects (such as FreeBSD) would make use of Kyua too for
   62: their testing needs, and if that happened we would be able to share tests
   63: with them pretty easily.  Forcing a portable codebase in the upstream
   64: repository helps in this.  (Be aware that different individuals from
   65: FreeBSD and Minix have shown interest in adopting Kyua for their respective
   66: systems!)
   67: 
   68: # Main differences (aka "what to expect")
   69: 
   70: As of version 0.5, Kyua has (or is supposed to have) feature parity with
   71: the ATF tools.  That said, having feature parity does not imply that they
   72: are the same.  This section outlines a few of the differences that you
   73: should be aware of before continuing.
   74: 
   75: ## Results database
   76: 
   77: Kyua collects the results of the execution of a test suite into an SQLite
   78: database.  User-friendly reports are later generated by extracting data
   79: from this same database.
   80: 
   81: In ATF, the results of the execution were written to an internal format
   82: that only atf-report could understand.  Despite of the database, Kyua still
   83: maintains the separation of "tests execution" from "report generation".
   84: 
   85: The contents of the database are immutable and incremental.  This means
   86: that, in the future, the Kyua tools will be able to provide historical data
   87: for particular test cases, or for whole test runs (which is what other
   88: NetBSD developers have ended up implementing multiple times outside of ATF
   89: because the framework did not provide such functionality by itself).
   90: 
   91: ## Support for multiple test interfaces
   92: 
   93: Kyua has support for different "test interfaces", which means that Kyua can
   94: execute test programs written using different paradigms and collect their
   95: results into a single report.  At the moment, two interfaces are supported:
   96: 
   97: * The "atf" interface provides compatibility with those test programs that
   98:   use the ATF libraries.  This is the only interface currently used by the
   99:   NetBSD test suite, as there is no way to run any other test program in an
  100:   automated manner.
  101: 
  102: * The "plain" interface permits the execution of legacy test programs that
  103:   do not use any testing library.  Such test programs are those that just
  104:   return 0 or non-0 to indicate the success or failure of the test
  105:   (respectively).  This feature will allow the NetBSD test suite to
  106:   transparently execute third-party test suites (such as the IPF or GCC
  107:   test suites) without having to implement ATF-based wrappers.  It will
  108:   also lower the barrier of entry to writing test programs for NetBSD, as
  109:   using the ATF libraries will become optional.
  110: 
  111: ## Lua configuration files
  112: 
  113: Kyua has two kind of configuration files: the Kyuafiles, which are the
  114: files shipped with a test suite that describe what test programs need to be
  115: run; and the user configuration files, which specify the run-time settings
  116: of Kyua and the test suites.  ATF had this same split of configuration
  117: files, and they were written in a custom language, with a custom parser.
  118: 
  119: The Kyua configuration files are all Lua scripts.  The major advantage of
  120: this at the moment is that their syntax will be familiar to end users, and
  121: that the parser for these files is well-tested.  In the future, the use of
  122: Lua will allow the implementation of more-intelligent test (and maybe even
  123: build) scripts.
  124: 
  125: ## Direct HTML output
  126: 
  127: All of the NetBSD continous build and testing systems provide status
  128: reports through the releng web interface.  In the case of ATF, this has
  129: traditionally been tricky because ATF cannot generate HTML contents
  130: directly; instead, `atf-report` generates XML output which later must be
  131: postprocessed with `xsltproc` to create the HTML pages.
  132: 
  133: Kyua has the ability to generate HTML reports straight from the tool,
  134: without having to go through any XML toolchain.  This means that NetBSD,
  135: out of the box, can generate such reports and publish them with the builtin
  136: httpd(8) server.
  137: 
  138: ## Heavier code base
  139: 
  140: If you take a look at the Kyua distribution file, you may notice that it is
  141: about the same size as the distribution file of ATF, yet Kyua does not
  142: currently replace the ATF libraries.  This may be surprising because it
  143: seems to imply that the codebase of Kyua is bigger because it "just"
  144: reimplements atf-run and atf-report: i.e. by just reimplementing parts of
  145: ATF, it is already as big as the whole of ATF.
  146: 
  147: This is true, for two reasons.
  148: 
  149: The first is that Kyua is more featureful and flexible: the features
  150: outlined above have a cost in terms of implementation, and the codebase of
  151: Kyua is more carefully crafted to allow for later growth.  In particular,
  152: all OS-specific details have been abstracted for easier portability, and
  153: the SQLite and Lua libraries have been wrapped for safety.
  154: 
  155: The second is that Kyua is much better tested (which is very important for
  156: a software package that you will rely on to validate your own software!).
  157: To give you some numbers, ATF 0.16 contains around 400 test cases for both
  158: atf-run and atf-report while Kyua 0.5 contains around 1100 test cases.
  159: 
  160: # Components
  161: 
  162: Kyua, as a project, is made up of a variety of components (which *include*
  163: ATF, because the ATF libraries are *not* being rewritten).  All of these
  164: components exist in pkgsrc, and are:
  165: 
  166: * pkgsrc/devel/atf-libs: The C, C++ and POSIX shell libraries provided by
  167:   ATF.  These are *NOT* meant to be replaced by Kyua.
  168: 
  169: * pkgsrc/devel/atf: The ATF tools, namely atf-run and atf-report.  These
  170:   are deprecated and this package should eventually disappear.
  171: 
  172: * pkgsrc/devel/kyua-cli: The Kyua command-line interface, which provides a
  173:   superset of the functionality of atf-run and atf-report.
  174: 
  175: * pkgsrc/devel/kyua-atf-compat: Drop-in replacements for atf-run and
  176:   atf-report that use kyua-cli in the backend.
  177: 
  178: # Running the NetBSD test suite
  179: 
  180: There are two ways to run the NetBSD test suite with Kyua.  The easy (or
  181: trivial) way is to use the backwards compatibility ATF tools, and the more
  182: sophisticated way is to convert the test suite to Kyua and use the native
  183: Kyua binary.  This section explains both approaches.
  184: 
  185: ## Using the ATF compatibility tools
  186: 
  187: The easiest (but also the least "future-proof") way to run the NetBSD test
  188: suite with Kyua is to use the backwards compatibility ATF tools provided by
  189: the kyua-atf-compat module.  First of all, install the package:
  190: 
  191:     $ cd /usr/pkgsrc/deve/kyua-atf-compat
  192:     $ make install && make clean
  193: 
  194: And then, running the test suite is as easy as:
  195: 
  196:     $ cd /usr/tests
  197:     $ /usr/pkg/bin/atf-run | /usr/pkg/bin/atf-report
  198: 
  199: Please be aware that if the atf-run and atf-report tools provided by
  200: kyua-atf-compat appear in your PATH before the real atf-run and atf-report
  201: tools shipped by NetBSD, you will experience test failures for all the
  202: tests in /usr/tests/atf/atf-run and /usr/tests/atf/atf-report.  This is
  203: expected: while the compatibility tools behave similarly to the real tools
  204: from a user's perspective, they are not fully interchangeable.  (For
  205: example, the serialization format between atf-run and atf-report is
  206: different.)
  207: 
  208: One property of the atf-run wrapper is that it uses the default results
  209: database in ~/.kyua/store.db to record the execution of the tests.  This
  210: means that, once the execution of the tests is done with the compatibility
  211: tools, you can still use the native Kyua binary to poke at the results
  212: database.  More on this below.
  213: 
  214: ## Using the native Kyua command-line interface
  215: 
  216: The preferred way to run the NetBSD test suite with Kyua is to use the
  217: native Kyua command-line binary.  This is the preferred method because it
  218: trains you to use the new interface rather than relying on the old pipeline
  219: and because it exposes you to all the new features of Kyua.  Regardless,
  220: this and the previous approach will yield the same results for a particular
  221: execution.
  222: 
  223: Using the native command-line interface is a multi-step process because
  224: the existing NetBSD test suite is not prepared for Kyua.  Let's take a look
  225: at these steps.
  226: 
  227: To get started, install the Kyua packages:
  228: 
  229:     $ cd /usr/pkgsrc/deve/kyua-cli
  230:     $ make install && make clean
  231:     $ cd /usr/pkgsrc/deve/kyua-atf-compat
  232:     $ make install && make clean
  233: 
  234: Once this is done, configure Kyua in the same way ATF is configured "out of
  235: the box" in NetBSD.  Create the /usr/pkg/etc/kyua/kyua.conf file with these
  236: contents:
  237: 
  238:     syntax('config', 1)
  239:     unprivileged_user = '_tests'
  240: 
  241: The next step is to populate /usr/tests with Kyuafiles, as Kyua is unable
  242: to read existing Atffiles.  This is easy to do with the atf2kyua(1) tool
  243: shipped in the kyua-atf-compat package:
  244: 
  245:     # atf2kyua /usr/tests
  246: 
  247: And that is it.  You can now execute the test suite using Kyua with any of
  248: the following two forms:
  249: 
  250:     $ cd /usr/tests && kyua test
  251:     $ kyua test -k /usr/tests/Kyuafile
  252: 
  253: Note that none of these will generate "pretty" reports.  These commands
  254: will only record the results of the execution into the database.  In order
  255: to generate reports, keep reading.
  256: 
  257: # Generating reports
  258: 
  259: Once you have ran the NetBSD test suite with any of the mechanisms above,
  260: the results of the execution have been stored in the "Kyua store", which is
  261: a database located in ~/.kyua/store.db by default.  (This path can be
  262: changed at any time with the --store flag.)
  263: 
  264: To extract a report from the database using the results of the latest tests
  265: run, you can run any of the following:
  266: 
  267:     $ kyua report -o my-report.txt
  268:     $ kyua html-report -o /var/www/results/
  269: 
  270: # Support and feedback
  271: 
  272: The Kyua manual is available in the GNU Info format and can be accessed by
  273: running:
  274: 
  275:     $ info kyua
  276: 
  277: Alternatively, use the help subcommand to get built-in documentation.  The
  278: following invocation will print all the available subcommands:
  279: 
  280:     $ kyua help
  281: 
  282: And an invocation like this will show you all the possible options for a
  283: given subcommand:
  284: 
  285:     $ kyua help report-html
  286: 
  287: If you have gone through the instructions above and started playing with
  288: Kyua, please do not hesitate to report your experiences (either good or
  289: bad) to [Julio Merino](mailto:jmmv@NetBSD.org)!  Any comments will be
  290: highly appreciated and will be taken into account for the near future of
  291: Kyua.

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb