From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [Bug 1357] Test/test suite pattern
Date: Wed, 10 Jan 2024 10:58:19 +0000 [thread overview]
Message-ID: <bug-1357-3@http.bugs.dpdk.org/> (raw)
[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]
https://bugs.dpdk.org/show_bug.cgi?id=1357
Bug ID: 1357
Summary: Test/test suite pattern
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: dts
Assignee: dev@dpdk.org
Reporter: juraj.linkes@pantheon.tech
CC: juraj.linkes@pantheon.tech, probb@iol.unh.edu
Target Milestone: ---
A test defines a testing procedure without any particular values to test. A
test case is a particular instance of a test with all the values defined.
A usual pattern of test case development is a test method implementing the test
procedure and a number of test cases calling the procedure with different
values.
If there are multiple variables with different values, the number of (possible)
test cases could be very high, which would be tedious and error-prone to
implement and maintain. This could be alleviated with scripts, but at that
point, we could have a more centrallized solution where the definition of test
cases could be just a matrix/dictionary of all the vectors of values to test.
The question is whether this is worth implementing (Are there going to be that
many test cases? Do we want that many?)?
The solution needs to be cognisant of how the test cases are going to be
executed and recorded and most importantly, how are they going to be recorded
in case they're blocked or skipped (i.e. when not executed).
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #2: Type: text/html, Size: 3570 bytes --]
reply other threads:[~2024-01-10 10:58 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=bug-1357-3@http.bugs.dpdk.org/ \
--to=bugzilla@dpdk.org \
--cc=dev@dpdk.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).