All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Kent Gibson <warthog618@gmail.com>
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
	"Bartosz Golaszewski" <brgl@bgdev.pl>,
	"Vincent Guittot" <vincent.guittot@linaro.org>,
	linux-gpio@vger.kernel.org,
	"Miguel Ojeda" <miguel.ojeda.sandonis@gmail.com>,
	"Wedson Almeida Filho" <wedsonaf@google.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	stratos-dev@op-lists.linaro.org,
	"Gerard Ryan" <g.m0n3y.2503@gmail.com>
Subject: Re: [PATCH V4 7/8] libgpiod: Add rust tests
Date: Wed, 27 Jul 2022 15:29:55 +0530	[thread overview]
Message-ID: <20220727095955.s4ymsu7wg6cmddey@vireshk-i7> (raw)
In-Reply-To: <20220727025847.GG88787@sol>

On 27-07-22, 10:58, Kent Gibson wrote:
> On Fri, Jul 08, 2022 at 05:05:00PM +0530, Viresh Kumar wrote:
> Don't include the test results in the commit message.
> Those are more of a release artifact than a commit artifact.
> It is assumed the tests pass for you or you wouldn't be submitting them.

I wasn't trying to prove that I tested them :)

The idea was to show how module/test names eventually look in the output.

Maybe I could have just replied to this email and pasted it, sure commit message
doesn't need it.

> > diff --git a/bindings/rust/tests/chip.rs b/bindings/rust/tests/chip.rs
> > +    mod configure {
> > +        use super::*;
> > +        const NGPIO: u64 = 16;
> > +        const LABEL: &str = "foobar";
> > +
> > +        #[test]
> > +        fn verify() {
> > +            let sim = Sim::new(Some(NGPIO), Some(LABEL), true).unwrap();
> > +            let chip = Chip::open(sim.dev_path()).unwrap();
> > +
> > +            assert_eq!(chip.get_label().unwrap(), LABEL);
> > +            assert_eq!(chip.get_name().unwrap(), sim.chip_name());
> > +            assert_eq!(chip.get_path().unwrap(), sim.dev_path());
> > +            assert_eq!(chip.get_num_lines(), NGPIO as u32);
> > +            chip.get_fd().unwrap();
> > +        }
> > +
> 
> A test for a basic open on an existing chip and a smoke test of some
> chip methods is called "verify", so chip::configure::verify?

You want me to rename this ? Sorry, got confused :(

Yeah, I am generally bad with naming, suggestions are welcome here :)

> > +        #[test]
> > +        fn line_lookup() {
> > +            let sim = Sim::new(Some(NGPIO), None, false).unwrap();
> > +            sim.set_line_name(0, "zero").unwrap();
> > +            sim.set_line_name(2, "two").unwrap();
> > +            sim.set_line_name(3, "three").unwrap();
> > +            sim.set_line_name(5, "five").unwrap();
> > +            sim.set_line_name(10, "ten").unwrap();
> > +            sim.set_line_name(11, "ten").unwrap();
> > +            sim.enable().unwrap();
> > +
> > +            let chip = Chip::open(sim.dev_path()).unwrap();
> > +
> > +            // Success case
> > +            assert_eq!(chip.find_line("zero").unwrap(), 0);
> > +            assert_eq!(chip.find_line("two").unwrap(), 2);
> > +            assert_eq!(chip.find_line("three").unwrap(), 3);
> > +            assert_eq!(chip.find_line("five").unwrap(), 5);
> > +
> > +            // Success with duplicate names, should return first entry
> > +            assert_eq!(chip.find_line("ten").unwrap(), 10);
> > +
> > +            // Failure
> > +            assert_eq!(
> > +                chip.find_line("nonexistent").unwrap_err(),
> > +                ChipError::OperationFailed("Gpio Chip find-line", IoError::new(ENOENT))
> > +            );
> > +        }
> 
> If it is testing find_line() then why not call it find_line?

I think I picked many names from the TEST_CASE name from cxx bindings. This was
written there as:

TEST_CASE("line lookup by name works", "[chip]")

and I didn't think much about it :)

Sure I can name this find_line().

> > diff --git a/bindings/rust/tests/edge_event.rs b/bindings/rust/tests/edge_event.rs
> > +        #[test]
> > +        fn wait_timeout() {
> > +            let mut config = TestConfig::new(NGPIO).unwrap();
> > +            config.rconfig(Some(&[0]));
> > +            config.lconfig_edge(Some(Edge::Both));
> > +            config.request_lines().unwrap();
> > +
> > +            // No events available
> > +            assert_eq!(
> > +                config
> > +                    .request()
> > +                    .wait_edge_event(Duration::from_millis(100))
> > +                    .unwrap_err(),
> > +                ChipError::OperationTimedOut
> > +            );
> > +        }
> 
> Is a timeout really a "failure"?
> 
> It is testing wait_edge_event(), which is a method of line_request,
> and so should be in the line_request test suite.

Copied it from cxx again, I just tried to add similar tests in similar files.

TEST_CASE("edge_event wait timeout", "[edge-event]")

> > +
> > +        #[test]
> > +        fn dir_out_edge_failure() {
> > +            let mut config = TestConfig::new(NGPIO).unwrap();
> > +            config.rconfig(Some(&[0]));
> > +            config.lconfig(Some(Direction::Output), None, None, Some(Edge::Both), None);
> > +
> > +            assert_eq!(
> > +                config.request_lines().unwrap_err(),
> > +                ChipError::OperationFailed("Gpio LineRequest request-lines", IoError::new(EINVAL))
> > +            );
> > +        }
> > +    }
> > +
> 
> This is testing a failure mode of request_lines(), not edge_events.
> Where is the edge_event here?

I agree, I will move this out.

This needs fixing too though.

TEST_CASE("output mode and edge detection don't work together", "[edge-event]")

> > diff --git a/bindings/rust/tests/info_event.rs b/bindings/rust/tests/info_event.rs
> > new file mode 100644
> > index 000000000000..96d8385deadf
> > --- /dev/null
> > +++ b/bindings/rust/tests/info_event.rs
> > @@ -0,0 +1,126 @@
> > +// SPDX-License-Identifier: Apache-2.0 AND BSD-3-Clause
> > +//
> > +// Copyright 2022 Linaro Ltd. All Rights Reserved.
> > +//     Viresh Kumar <viresh.kumar@linaro.org>
> > +
> > +mod common;
> > +
> > +mod info_event {
> > +    use libc::EINVAL;
> > +    use std::sync::Arc;
> > +    use std::thread::{sleep, spawn};
> > +    use std::time::Duration;
> > +
> > +    use vmm_sys_util::errno::Error as IoError;
> > +
> > +    use crate::common::*;
> > +    use libgpiod::{Chip, Direction, Error as ChipError, Event, LineConfig, RequestConfig};
> > +
> > +    fn request_reconfigure_line(chip: Arc<Chip>) {
> > +        spawn(move || {
> > +            sleep(Duration::from_millis(10));
> > +
> > +            let lconfig1 = LineConfig::new().unwrap();
> > +            let rconfig = RequestConfig::new().unwrap();
> > +            rconfig.set_offsets(&[7]);
> > +
> > +            let request = chip.request_lines(&rconfig, &lconfig1).unwrap();
> > +
> > +            sleep(Duration::from_millis(10));
> > +
> > +            let mut lconfig2 = LineConfig::new().unwrap();
> > +            lconfig2.set_direction_default(Direction::Output);
> > +
> > +            request.reconfigure_lines(&lconfig2).unwrap();
> > +
> > +            sleep(Duration::from_millis(10));
> > +        });
> > +    }
> > +
> 
> Benefit of the background thread?

Again copied from cxx, I think the idea here is to get the events one by one and
read one before the next one is generated. i.e. to do it all in parallel, which
looked fine to me.

> > +    mod properties {
> > +        use super::*;
> > +
> > +        #[test]
> > +        fn verify() {
> > +            let sim = Sim::new(Some(NGPIO), None, false).unwrap();
> > +            sim.set_line_name(1, "one").unwrap();
> > +            sim.set_line_name(2, "two").unwrap();
> > +            sim.set_line_name(4, "four").unwrap();
> > +            sim.set_line_name(5, "five").unwrap();
> > +            sim.hog_line(3, "hog3", GPIOSIM_HOG_DIR_OUTPUT_HIGH as i32)
> > +                .unwrap();
> > +            sim.hog_line(4, "hog4", GPIOSIM_HOG_DIR_OUTPUT_LOW as i32)
> > +                .unwrap();
> > +            sim.enable().unwrap();
> > +
> > +            let chip = Chip::open(sim.dev_path()).unwrap();
> > +            chip.line_info(6).unwrap();
> > +
> > +            let info4 = chip.line_info(4).unwrap();
> > +            assert_eq!(info4.get_offset(), 4);
> > +            assert_eq!(info4.get_name().unwrap(), "four");
> > +            assert_eq!(info4.is_used(), true);
> > +            assert_eq!(info4.get_consumer().unwrap(), "hog4");
> > +            assert_eq!(info4.get_direction().unwrap(), Direction::Output);
> > +            assert_eq!(info4.is_active_low(), false);
> > +            assert_eq!(info4.get_bias().unwrap(), Bias::Unknown);
> > +            assert_eq!(info4.get_drive().unwrap(), Drive::PushPull);
> > +            assert_eq!(info4.get_edge_detection().unwrap(), Edge::None);
> > +            assert_eq!(info4.get_event_clock().unwrap(), EventClock::Monotonic);
> > +            assert_eq!(info4.is_debounced(), false);
> > +            assert_eq!(info4.get_debounce_period(), Duration::from_millis(0));
> > +        }
> > +    }
> 
> Test that you can read all supported values for all fields.

Like setting bias to all possible values one by one and reading them back ? Or
something else ?

> Clippy warnings to fix:
> 
> $cargo clippy --tests

I just ran

cargo clippy --workspace --bins --examples --benches --all-features -- -D warnings

and thought it works for tests too, my bad.

-- 
viresh

  reply	other threads:[~2022-07-27 10:00 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-08 11:34 [PATCH V4 0/8] libgpiod: Add Rust bindings Viresh Kumar
2022-07-08 11:34 ` [PATCH V4 1/8] libgpiod: Add libgpiod-sys rust crate Viresh Kumar
2022-07-27  2:57   ` Kent Gibson
2022-07-27  4:51     ` Viresh Kumar
2022-07-27  5:17       ` Kent Gibson
2022-07-27  5:45         ` Viresh Kumar
2022-08-01 12:11         ` Viresh Kumar
2022-08-01 15:56           ` Kent Gibson
2022-08-02  8:50             ` Viresh Kumar
2022-08-02  9:36               ` Kent Gibson
2022-07-08 11:34 ` [PATCH V4 2/8] libgpiod: Add pre generated rust bindings Viresh Kumar
2022-07-27  2:57   ` Kent Gibson
2022-07-27  5:15     ` Viresh Kumar
2022-07-27  5:31       ` Kent Gibson
2022-07-27  6:00         ` Viresh Kumar
2022-07-27  6:06           ` Kent Gibson
2022-07-08 11:34 ` [PATCH V4 3/8] libgpiod-sys: Add support to generate gpiosim bindings Viresh Kumar
2022-07-27  2:57   ` Kent Gibson
2022-07-27  5:30     ` Viresh Kumar
2022-07-08 11:34 ` [PATCH V4 4/8] libgpiod: Add rust wrapper crate Viresh Kumar
2022-07-27  2:57   ` Kent Gibson
2022-07-27  9:07     ` Viresh Kumar
2022-07-27 10:08       ` Kent Gibson
2022-07-27 11:06         ` Miguel Ojeda
2022-07-27 12:40           ` Kent Gibson
2022-07-27 13:02             ` Miguel Ojeda
2022-07-28  3:11               ` Kent Gibson
2022-07-29  4:40                 ` Viresh Kumar
2022-07-28  3:10         ` Kent Gibson
2022-08-01 12:05         ` Viresh Kumar
2022-08-01 13:20           ` Kent Gibson
2022-08-01 13:28             ` Miguel Ojeda
2022-07-28  8:52     ` Viresh Kumar
2022-07-28  9:59       ` Kent Gibson
2022-07-08 11:34 ` [PATCH V4 5/8] libgpiod: Add rust examples Viresh Kumar
2022-07-27  2:58   ` Kent Gibson
2022-07-27  9:23     ` Viresh Kumar
2022-07-27  9:59       ` Kent Gibson
2022-07-27 10:06         ` Viresh Kumar
2022-07-27 10:32           ` Kent Gibson
2022-07-27 10:33             ` Viresh Kumar
2022-07-08 11:34 ` [PATCH V4 6/8] libgpiod: Derive debug traits for few definitions Viresh Kumar
2022-07-27  2:58   ` Kent Gibson
2022-07-27  6:20     ` Viresh Kumar
2022-07-08 11:35 ` [PATCH V4 7/8] libgpiod: Add rust tests Viresh Kumar
2022-07-27  2:58   ` Kent Gibson
2022-07-27  9:59     ` Viresh Kumar [this message]
2022-07-27 10:27       ` Kent Gibson
2022-08-01 11:54     ` Viresh Kumar
2022-08-01 12:38       ` Kent Gibson
2022-08-02  5:44         ` Viresh Kumar
2022-08-02  5:47           ` Kent Gibson
2022-07-08 11:35 ` [PATCH V4 8/8] libgpiod: Integrate building of rust bindings with make Viresh Kumar
2022-07-27  2:59   ` Kent Gibson
2022-07-27  6:18     ` Viresh Kumar
2022-07-27  6:25       ` Kent Gibson
2022-07-27  6:35         ` Viresh Kumar
2022-07-27  6:45           ` Kent Gibson
2022-07-27  6:51             ` Viresh Kumar
2022-07-15 19:07 ` [PATCH V4 0/8] libgpiod: Add Rust bindings Bartosz Golaszewski
2022-07-15 19:17   ` Miguel Ojeda
2022-07-15 19:27     ` Miguel Ojeda
2022-07-16  9:43       ` Miguel Ojeda
2022-07-16 10:43         ` Bartosz Golaszewski
2022-07-16 12:23           ` Kent Gibson
2022-07-16 13:46           ` Miguel Ojeda

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=20220727095955.s4ymsu7wg6cmddey@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=alex.bennee@linaro.org \
    --cc=brgl@bgdev.pl \
    --cc=g.m0n3y.2503@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=stratos-dev@op-lists.linaro.org \
    --cc=vincent.guittot@linaro.org \
    --cc=warthog618@gmail.com \
    --cc=wedsonaf@google.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 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.