From: Marco Pagani <marpagan@redhat.com>
To: Xu Yilun <yilun.xu@intel.com>
Cc: Moritz Fischer <mdf@kernel.org>, Wu Hao <hao.wu@intel.com>,
Tom Rix <trix@redhat.com>,
linux-kernel@vger.kernel.org, linux-fpga@vger.kernel.org
Subject: Re: [RFC PATCH v6 3/4] fpga: add an initial KUnit suite for the FPGA Region
Date: Mon, 5 Jun 2023 18:58:56 +0200 [thread overview]
Message-ID: <d1ef2f9a-f416-e7d6-7481-d81c1941702e@redhat.com> (raw)
In-Reply-To: <ZHuQc7WfN1zKOeTE@yilunxu-OptiPlex-7050>
On 2023-06-03 21:11, Xu Yilun wrote:
> On 2023-05-31 at 11:54:04 +0200, Marco Pagani wrote:
>> The suite tests the programming of an FPGA Region with a Bridge
>> and the function for finding a particular Region.
>>
>> Signed-off-by: Marco Pagani <marpagan@redhat.com>
>> ---
>> drivers/fpga/tests/fpga-region-test.c | 186 ++++++++++++++++++++++++++
>> 1 file changed, 186 insertions(+)
>> create mode 100644 drivers/fpga/tests/fpga-region-test.c
[...]
> Maybe better just put all tests in one module, and have unified
> fake_mgr_ops/mgr_stats/fake_bridge_ops/bridge_stats across all tests.
>
> In previous thread, I said I'm good to the self-contained test module
> but I didn't actually follow the idea. Sorry for that.
>
> The concern is why in this region test, the write_count and only the
> write_count is taken care of.
>
> Although fpga_mgr_load() test covers all mgr_ops, but does that
> means these ops are still good for more complex case like
> fpga_region_program_fpga()? And there is no guarantee
> fpga_region_program_fpga() would always call mgr_ops the same way
> as fpga_mgr_load() in future.
>
> Similar for fpga_bridge. Maybe a complete setup for fpga_region is
> still necessary.
I think that putting all tests in a single module (like in previous
versions) goes against the principles of unit testing, making the
code more similar to an integration test.
Unit tests should be focused on a single behavior. The programming
test case included in the Region's suite should test only the behavior
of the Region itself. Specifically, that fpga_region_program_fpga() calls
get_bridges(), to get and control bridges, and then the Manager for the
actual programming.
The programming sequence itself is outside the responsibilities of the
Region, and its correctness is already ensured by the Manager suite.
Similarly, the correctness of the Bridge's methods used by the Region
for getting and controlling multiple bridges is already ensured by the
Bridge test suite.
For this reason, the Manager and Bridge fakes used in the Region suite
implement only the minimal set of operations necessary to ensure the
correctness of the Region's behavior. If I used a "full" Manager (and
tested all mgr_ops), then the test case would have become an integration
test rather than a unit test for the Region.
> BTW: I like the way that fake drivers are removed. Looks much straight
> forward.
I appreciate that.
> Thanks,
> Yilun
>
Thanks,
Marco
[...]
next prev parent reply other threads:[~2023-06-05 17:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-31 9:54 [RFC PATCH v6 0/4] fpga: add initial KUnit tests for the subsystem Marco Pagani
2023-05-31 9:54 ` [RFC PATCH v6 1/4] fpga: add an initial KUnit suite for the FPGA Manager Marco Pagani
2023-05-31 9:54 ` [RFC PATCH v6 2/4] fpga: add an initial KUnit suite for the FPGA Bridge Marco Pagani
2023-05-31 9:54 ` [RFC PATCH v6 3/4] fpga: add an initial KUnit suite for the FPGA Region Marco Pagani
2023-06-03 19:11 ` Xu Yilun
2023-06-05 16:58 ` Marco Pagani [this message]
2023-06-06 11:00 ` Xu Yilun
2023-06-07 15:57 ` Marco Pagani
2023-06-09 11:09 ` Xu Yilun
2023-06-09 10:35 ` Marco Pagani
2023-06-09 11:22 ` Xu Yilun
2023-06-09 10:41 ` Marco Pagani
2023-05-31 9:54 ` [RFC PATCH v6 4/4] fpga: add configuration for the KUnit test suites Marco Pagani
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=d1ef2f9a-f416-e7d6-7481-d81c1941702e@redhat.com \
--to=marpagan@redhat.com \
--cc=hao.wu@intel.com \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mdf@kernel.org \
--cc=trix@redhat.com \
--cc=yilun.xu@intel.com \
/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).