On 12/02/2016 04:54 PM, Laszlo Ersek wrote: > On 12/02/16 22:16, Eduardo Habkost wrote: >> On Fri, Dec 02, 2016 at 10:01:52PM +0100, Laszlo Ersek wrote: >> [...] >>> +docs/* >>> +*.txt >>> +configure >>> +GNUmakefile >>> +makefile >>> +Makefile* >>> +*.mak >>> +qapi-schema*.json >>> +qapi/*.json >>> +include/qapi/visitor.h >>> +include/qapi/visitor-impl.h >>> +scripts/qapi.py >>> +scripts/*.py >>> +*.h >>> +qapi/qapi-visit-core.c >> >> Maybe we could include test/* here, so test code appears before >> the implementation? > > Hmmm, I'm not so sure about that. I certainly don't subscribe to TDD, > when you first write up the test case, and then add implementation to > satisfy the tests. > > I don't have much experience / history with the tests subdir. Briefly > reviewing what I've done there (git log --author=lersek), I think I > would either keep the test patches entirely separate from the QEMU code > patches (thus there wouldn't be a patch modifying *.c files both under > and outside of tests/). Or else, I would actually prefer tests/*.c to > come later in the same patch. The tests are frequently written to > provide good coverage for the actual QEMU code, so seeing the QEMU code > first seems preferable. (The corner cases to cover could be completely > arbitrary, originating from quirks of POSIX functions, and so on.) > > Thanks > Laszlo > >>> +*.c >>> -- >>> 2.9.2 >>> >>> >> >
We also don't formally embrace TDD, as any tests that are checked in _MUST_ pass. The patch order by definition then requires the feature first, and then the tests. Personally I like TDD, but I don't think it's appropriate to put tests first in this instance, as we review with an eye for "Will this break the tree right now?" and not "What are we about to add to QEMU?" --js
