Hi Julian (2024.09.09_15:19:51_+0000)
> That seems a bit heavy to ask for.
>
> Is there any way of identifying those packages that do genuinely use
> unittest?
From 6438 build logs:
- 651 don't call dh_auto_test
- 2180 do something custom
- 1989 use pytest
- 25 use nose
- 18 use nose2
- 23 use tox
- 3 use stestr
- 1561 packages use pybuild's unittest runner
* 391 pass
* 1170 fail
+ 1139 NO TESTS RAN
+ 33 the test suite failed
(numbers don't quite add up, because this was a lot of grep | wc -l)
> If there are not that many of them, then implementing a
> --test-unittest option would be a good way to go. I would imagine the
> following timeline:
>
> (1) --test-unittest is introduced as an option to explicitly select
> unittest as the test framework. When --test-unittest is specified,
> the test will fail if no tests are found. unittest is still used as a
> fallback test framework; in this case, the dh_auto_test call will
> succeed if no tests are run.
>
> (2) Add some sort of warning for pybuild-using packages that run
> dh_auto_test but haven't specified a test framework and for which
> autodetection of the test framework fails. If there aren't any tests
> to run, an empty override_dh_auto_test target should be specified.
>
> (3) Stop using unittest as the default test framework, and fail if no
> test framework has been specified or autodetected.
>
> But that might be overkill for something which may not actually be
> much of a problem.
Yeah, that can work. We can also just abort after step 2.
Stefano
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
