Re: unit testing for fio?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm just going to top reply, since I can't address everything below
and the thread is already somewhat of a mess :-)

I'd welcome any efforts into adding unit tests. I've never had time
to do that myself, but I think it would be a huge win for fio to have
that. Back when I had a bit more time, I sometimes added a job that
would demonstrate a bug when I committed a fix. There's a couple
in t/jobs/. But I wasn't very persistent in doing that, unfortunately.

But I'd love to be able to commit code that looks a little scary,
and run the unit tests and at least have a bit more confidence that
we didn't break strange corner cases or re-introduced a regression.
In many ways, I think this is the most important thing that fio is
missing right now.


On 06/14/2017 12:17 AM, Sitsofe Wheeler wrote:
> Resending thread explicitly to Jens (thread may be difficult to read
> because we have both top and bottom posting)...
> 
> On 7 June 2017 at 21:52, Brantley West <cbwest@xxxxxxxxx> wrote:
>> @vincentfu I'm in the same boat, not familiar with the features and
>> caveats of the different options to make an informed recommendation at
>> present.
>>
>> @sitsofe I agree, I think a `make unittest` that is incorporated into
>> CI would be wonderful.  Even better - if it generates a code/branch
>> coverage report.  Other projects I'm involved with require unit
>> testing to provide code & branch coverage for any modified code before
>> being merged.  I think a similar strategy would be beneficial,
>> however, I'm the least likely to be impacted by such a change in a
>> process.  At Nutanix different groups use different tools for
>> performance testing and validation, and it depends on who you talk to.
>> I've been a heavy Vdbench user (great tool), but am at a crossroads
>> where I'm reevaluating tools for a future project.  fio's open
>> development process is very appealing to me.
>>
>> If time allows, I'll test drive a few unit testing frameworks and
>> respond on thread w/ my branch.
>>
>> Jens, do you have any thoughts you can share?
>>
>> -bw
>> C. Brantley West, III
>> cbwest@xxxxxxxxx
>>
>>
>> On Sat, Jun 3, 2017 at 9:29 AM, Tomohiro Kusumi
>> <kusumi.tomohiro@xxxxxxxxx> wrote:
>>> Hi
>>>
>>> 2017-06-03 16:07 GMT+03:00 Sitsofe Wheeler <sitsofe@xxxxxxxxx>:
>>>> On 2 June 2017 at 20:30, Brantley West <cbwest@xxxxxxxxx> wrote:
>>>>>
>>>>> I'm looking to adopt fio for some storage testing in the near future
>>>>> and have noticed a few issues (#377, #378) that seem to be
>>>>> math-related.  Assuming these issues get fixed, it seems like unit
>>>>> testing would help ensure they stay fixed.  Additionally, fio has a
>>>>> lot of useful configuration options, and unit tests seem like a good
>>>>> way to test for expected operation when multiple configuration
>>>>> parameters are present.
>>>>>
>>>>> Is a unit test framework something that is worth considering for fio?
>>>>> If so, are there any preferences?  It seems there are multiple options
>>>>> (check, cunit, unity, etc).
>>>>
>>>> I think it would be useful if there was an explicit make selftest
>>>> target for fio which could do more rigorous checks than my "does it
>>>> run?" make test. fio has the odd adhoc test (e.g.
>>>> https://github.com/axboe/fio/tree/master/unit_tests ) and now I look I
>>>> spy the odd test for checking certain job files for regressions too
>>>> (see https://github.com/axboe/fio/tree/master/t/jobs ). It would be
>>>> nice to run these and more via CI (travis/appveyor) on commit though
>>>> (assuming they finish quickly)...
>>>>
>>>> Some pieces of fio have been broken out into standalone programs (see
>>>> some of them in https://github.com/axboe/fio/tree/master/t/ ) which
>>>> might make testing for correctness easier. Perhaps Tomohiro Kusumi
>>>> (who has made pieces of fio more standalone) will be able to make
>>>> suggestions?
>>>
>>> Yes.
>>> Things under os/ arch/ lib/ oslib/ are mostly stand-alone utility
>>> functions now (i.e. you can include them or link to them via your
>>> main()), so those are probably easy to do unit testing using cunit or
>>> variants.
>>>
>>> Others more or less have dependencies on fio itself (and there isn't
>>> anything wrong with that too), so those are not as easy, or maybe
>>> depends on what you mean by unit testing.
>>>
>>>>
>>>> Personally I've used cunit (via the libiscsi project) but I've never
>>>> compared all C unit test frameworks. Further, the fio build doesn't
>>>> seem to add many dependencies on other libraries (other than for I/O
>>>> engines)...
>>>>
>>>> Way back in 2008 there was a proposal to add a "make check" to fio
>>>> (http://maillist.kernel.dk/fio-devel/0584.html ) which looked like it
>>>> was readily accepted but it's unclear whether something was actually
>>>> produced...
>>>>
>>>> If you've got any pre-existing checks please post/link them!
>>>>
>>>> PS: Do you find fio useful at Nutanix and are there any other public
>>>> I/O exercisers you folks use?
> 


-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe fio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Linux SCSI]     [Linux IDE]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux