Re: [libgpiod][PATCH 1/1] gpio-tools-test.bats: modify delays in toggle test

[Kent Gibson <warthog618@gmail.com>]

On Tue, May 30, 2023 at 04:52:36PM +0200, Bartosz Golaszewski wrote:
> On Tue, May 30, 2023 at 4:24 PM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Tue, May 30, 2023 at 04:13:06PM +0200, Bartosz Golaszewski wrote:
> > > On Tue, May 30, 2023 at 12:05 PM Kent Gibson <warthog618@gmail.com> wrote:
> > > >
> > > > On Tue, May 30, 2023 at 11:51:05AM +0200, Bartosz Golaszewski wrote:
> > > > > On Thu, May 25, 2023 at 11:54 PM Slater, Joseph
> > > > > <joe.slater@windriver.com> wrote:
> > > > > >
> > > > > >
> > > > > > [Slater, Joseph] I'll get rid of the comment and try the test with a shorter toggle time.
> > > > > > The series of 159 tests takes, maybe, 10-15 minutes for me, so I don't think saving a
> > > > > > second or two here would make much difference, though.
> > > > > > Joe
> > > > > >
> > > > >
> > > > > That can't be right, are you running it on a toaster? It takes 26
> > > > > seconds on my regular lenovo thinkpad laptop which is still longer
> > > > > than I'd like but quite acceptable for now (though I agree it would be
> > > > > great to improve it).
> > > > >
> > > >
> > > > Consider yourself blessed.
> > > > I just got:
> > > >
> > > > real    2m25.956s
> > > >
> > > > on my test VM.
> > > > Not sure exactly what the hold up is - it isn't using much CPU, or any
> > > > other resources AFAICT.
> > > > Compared to all the other test suites I run, this is far and away the
> > > > slowest, especially since switching everything over to gpio-sim.
> > >
> > > I agree it's too slow - be it 20 seconds or 2 minutes. But similarly
> > > to you - it's very low on my TODO list as I only run it every once in
> > > a while. I'd be happy to accept any patches improving the situation of
> > > course.
> > >
> >
> > Same.  I already had a go at streamlining the tests when I updated them
> > for v2, so it is somewhat better than it was, but it is still painfully
> > slow for me.
> > To improve further I'd have to start digging around to see what bats is
> > up to.  Speaking of which, do we need to stick with bats?
> > I've driven similar tests with Python in the past, and I'm sure that
> > would provide a better experience.
> > What constraints do we have?
> >
> 
> I went with bats because it looked the fastest to write tests in -
> it's shell after all.
> 

Really?  I wouldn't write anything of consequence in shell if Python was
an option.

How about Rust?  I've gotten over how spartan the Rust test framework is
so I wouldn't have a problem writing it in that either.

> But I think that we could potentially package whatever python
> subprocess code we need into enough helper wrappers that it wouldn't
> be much more complex than this.
> 

The end result would look similar in terms of test complexity, but
should be much easier to write and debug.
Not that that counts for much given we have a functional bats test
suite.

> We also already have python wrappers for libgpiosim ready.
> 

Exactly.  And Rust bindings too.

> No objections from my side, it's just that I won't have time to
> rewrite the entire thing in Python anytime soon.
> 

I'll update my todo list.  No promises - it is low priority given the
only real problem with the bats solution is its performance.

Cheers,
Kent.