On Fri, 21 Mar 2014, Charles Plessy wrote: > For packages without upstream tests, in the meantime, even the most simple > tests like running the command with the --help option, are potentially useful.
+10 ;) I also try to run some Demo or Example script if such is provided (often via xvfb) to indeed catch the most broken beasts > My favorite example is T-COFFEE, where we were distributing a 100 % broken > package on arm for years. With autopkgtest, we will have a better overview on > what package works where (just a successful build is not enough), and this > will > help people to evaluate the feasiblity of projects based on Debian on amd64, > and also on more rarely used platforms (such as the Raspberry Pi as we read on > this list). well -- the best one IMHO here is the s390x -- big-endian 64bit. It helped to detect/iron out bugs for cases where unit-tests were not developed to test those corner cases, but which naturally appear when e.g. bytes get swapped ;) armel is my favorite to detect race conditions, since it is somewhat slower than regular x86, thus those race conditions do not come that obvious ;) > Slightly more complex tests can often be built from the examples in the > program's README. On my side, I am still on a learning phase with > autopkgtest, > but I hope that collectively we will have a clear vision on what to recommend > Upstream so that they can write or accept user-contributed tests are trivially > run by autopkgtest. well -- autopkgtest is indeed nice BUT for basic QA I do prefer build-time testing, since that guarantees that package with known issues doesn't even get to the users before issues get resolved. And it goes through testing on all supported architectures (if not architecture all of cause). My main reluctance with autopkgtest was the need to duplicate definition of 'running tests' twice in debian/rules and then under debian/tests... sadt seems might be of help to avoid this duplication now -- I will look later to see if that would be possible to just call it (with corresponding tune up of PATH/PYTHONPATH) with debian/rules... > I also like a lot the “litteral programming” side of the “reproducible > research” trend. I am developing some tutorials based on real data analyses > from my work, which are currently implemented in knitr > (http://yihui.name/knitr/), and which I hope to iron out so that they can be > used to test a Debian image in an integrated way. However, they currently > still use programs that are not yet packaged. ha -- being not R user much -- haven't heard about knitr. Looks interesting indeed. Python folks were blessed "recently" with IPython which now goes even stronger forward (thanks to support from Sloan foundation and others). If you managed to not hear about that: have a look at sample ipython notebooks at http://nbviewer.ipython.org/ . > Work in progress but comments welcome ! > https://github.com/charles-plessy/tutorial it is pity there is no some kind of 'knitrviewer.org' ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
