On 16/05/14 19:11, Amitai Schlair wrote: > I should have specified _automated_ tests. Are most people who write > device drivers really doing Test-Driven Development -- defining > each new intended behavior as a small and correctly failing test, > then doing just enough to make the next test pass, then cleaning > up a bit? With fine-grained tests, one or two new ones at a time, > over and over and over? I've been assuming otherwise, because the > fast feedback of TDD is usually too hard to arrange for in systems > programming. > > Enter rump. TDD is my favorite technique for efficiently learning > what to do, how to do it, and whether I've done it -- in application > development. Can I effectively apply TDD in a context where (1) > most people don't currently apply it and (2) my level of ignorance > is far more staggering than usual? My hypothesis is that with rump, > the answer becomes yes. A major selling point, IMO, if true.
Well, "let's do TDD" is a bit of a pointy-haired decision ;) You can't write meaningful fine-grained tests unless you know what you're doing, both with the device and in the general area. The 802.11-2012 standard is close to 3000 pages long, and I'm sure the manuals for wireless devices would be in the same ballpark if they were available (!). So, us folks who don't have expert knowledge are stuck to mapping device behaviour to high-level events that we can comprehend: * does it probe * does it attach * can I ifconfig up * can I attach to a network * can I send packets * can I receive packets * ... Yes, you can do TDD with rump kernels. Being able to do things in userspace instead of rebooting kernels speeds things up _A LOT_ when you try to figure out how you need to kick the hardware. However, that is not to be confused with knowing what you're doing. Most systems code is complex because systems code is complex, not because it's running in some magical hardware mode that makes code complex. I think the most useful thing to do for systems-oriented TDD is to write driver class specific high level tests, e.g. for networking cards, perhaps starting from the above list. Then develop it into a process so that anyone who actually has access one specific piece of hardware in the class can use to safely test if their device passes. That way we get rid of the "I can ping and firefox works, therefore the driver is perfect" mentality of testing. There is somewhat of an example of this approach in tests/fs/vfs. The class approach also has the benefit of being able to start with a known-working driver, and building your expertise from there by first observing what should go on in a driver when it's confronted with your tests. If you really want to do fine-grained TDD, I think you'll in any case end up doing TDTDD, when you need high-level tests to figure out what the suitable low-level tests are. But I can't tell you what you can or can't do, only one way to find out. - antti ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
