Hi Anto,

On Wed, May 27, 2015 at 6:19 AM, Anto <aryanto@???> wrote:

>
>
> On 25/05/15 18:29, Jude Nelson wrote:
>
>> Hey everyone,
>>
>> I have the latest news for vdev:
>>
>> .
> <snip>
> .
>
>> Thoughts and feedback to the above welcome :)
>> -Jude
>>
>>
> Thanks a lot Jude for all your efforts.
>
> Since you put a big fat warning "**CURRENTLY BROKEN. DO NOT ATTEMPT. WE
> ARE MIGRATING TO .DEB PACKAGES.**" on
> https://github.com/jcnelson/vdev/blob/master/how-to-test.md#appendix-b-booting-with-vdevd
> about 13 days ago, I have been waiting for your update on the deb build
> package script so I can continue testing. How far are we on that? Please do
> not assume that I am pushing you.
>
> If that would be quite far due to higher priorities on other parts of vdev
> development, how about if you included test cases for any parts of vdev
> that still need testing?
>
> For instance, a simple list like below would help novice testers like me
> (and hopefully help speeding up vdev development as it looks getting more
> complex):
>

> 1. Test Case A Title
>     Test Unit: vdev function X
>     Expected Result: <list of expected output or expected logs when the
> test pass>
>     Test Result: Pass or Fail
>     Test Log: <logs either when the test pass or fail>

>

> 2. Test Case B Title
>     Test Unit: vdev function B
>     Expected Result: <list of expected output or expected logs when the
> test pass>
>     Test Result: Pass or Fail
>     Test Log: <logs either when the test pass or fail>

>
> And so on.
>
> I think that will also help you shifting your priorities in putting your
> efforts on each parts of vdev development.
>
> Cheers,
>
> Anto
>
>
What you're asking for is a black-box test suite. In most software
systems, this is highly desirable, and is usually added into the CI so the
CI can verify that all tests pass before generating a package.

Unfortunately, systems like udev and vdev are exceptions--their "expected
results" are tightly-coupled to the underlying hardware. There's no way to
categorically describe the expected results without also describing all the
relevant aspects of the underlying hardware as well, and there are as many
different hardware configurations as there are users (so each user has a
different expected result). The best I can do is verify that vdev produces
a /dev that has the same files that udev would have created on the same
hardware.

I'm still figuring out the packaging. My goal is to add Makefile targets
to use fpm to generate packages (for testing and cross-distro
compatibility), and then worry about adding the Devuan-specific control
files to get vdev hooked into the CI system (ideally, I'd find a way to get
fpm to generate those for me too).

-Jude


> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>