All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Tim.Bird@sony.com>
To: fuego@lists.linuxfoundation.org
Subject: [Fuego] RFC - test/set/case documentation generation
Date: Thu, 8 Feb 2018 06:28:42 +0000	[thread overview]
Message-ID: <ECADFF3FD767C149AD96A924E7EA6EAF6445FDC1@USCULXMSG01.am.sony.com> (raw)

Hello all,

I'm writing to let you know about a project that I've started, having to do with
documenting tests, testsets, and test cases, as well as feeding into capabilities
for report generation.

It's a bit hard to describe the overall scope of the project, but it's quite big.
I want to document every testcase that Fuego performs.  This include a mixture
of human-written documentation, and reports of results from tests performed
on both local boards and eventually remote boards.

My plan is to add a 'docs' directory under each test directory.  Inside that
there will be template files, which describe tests, test sets, and individual test
cases.  My plan is that the fuego system can combine test result data, with
human-written text, in both HTML format (for use via the Jenkins intereface),
and PDF format (for use in PDFs that are generated as test reports).
The templates are written in reStructuredText, with macro directives
to indicate what dynamic data to add to the templates.

The template is processed by Fuego, and is output as an .rst file, which can
be used as is as a straight text file, or further processed by sphynx to convert
into either HTML (for access via the Jenkins interface) or latex (for publication
in PDF test reports).

It will likely take years to fill in all the testcases, but I expect that the list of
documented testcases will likely always be sparse.  Only the most important
testcases will be documented at first, and they can be filled in as we go along.
Having some testcases documented will be more useful than having no
testcases documented.

The first instance of this is not quite ready for usage yet, but you can get an idea
of what I have planned by looking at:
/fuego-core/engine/tests/Functional.LTP/docs/Functional.LTP.ftmp
('ftmp' stands for 'Fuego template')
This is processed by Fuego (by a program called gen-page.py) and
the output is placed in:
/fuego-rw/docs/Functional.LTP.rst
The intent is to further process this into
/fuego-rw/logs/Fucntional.LTP/Functional.LTP.html
and make that accessible via the Jenkins interface.

This is in my 'master' branch, at commit 0eba4e6

Note that the information in Functional.LTP.ftmp is a little out-of-date, and
the plan is to gather more information automatically (such as dependencies,
spec list, etc.) over time.

My idea is that using the same mechanisms, we will be able to generate reports
from test data, that are a mixture of testcase results, summary data, detailed
error reports, and human-written explanations of test operation and intent.

One problem this is intended to solve has to do with report generation.  But
another problem is that many of our tests are very opaque.  There's no
human-readable documentation on the operation of the tests, what the results
are supposed to mean, and what to do to resolve reported failures.  Creating a
documentation system like this will allow such human-generated text to be
presented alongside results, hopefully making results interpretation much easier.

Work on this is progressing slowly, due to other demands on my time.
But I wanted to present the idea to allow people to give feedback on it.

Please let me know what you think.

Regards,
 -- Tim

             reply	other threads:[~2018-02-08  6:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-08  6:28 Tim.Bird [this message]
2018-02-08 15:47 ` [Fuego] RFC - test/set/case documentation generation Gustavo Sverzut Barbieri
2018-02-08 18:22   ` Tim.Bird
2018-02-08 18:53     ` Gustavo Sverzut Barbieri
2018-02-08 19:29       ` Tim.Bird

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ECADFF3FD767C149AD96A924E7EA6EAF6445FDC1@USCULXMSG01.am.sony.com \
    --to=tim.bird@sony.com \
    --cc=fuego@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.