Hi all, I hope the *.perl.org filters won't give troubles to my title and content, but I've done it as a tribute to http://programming-motherfucker.com/ , which I recommend going over, being the anti-methodology/NoMethodology (but in part apparently written tongue-in-cheek), and which isn't too long a read, and also hosts the useful http://programming-motherfucker.com/become.html list of resources for learning.
So why am I writing this? I used to feel guilty about not being conscious of the distinction between the various scopes of tests, like unit tests vs. integration tests vs. system tests vs. functional tests etc. when I wrote the tests. I just noticed that I need a test here (as a regression test for a bug, or to TDD a new feature, or after implementing a new feature, etc.), and wrote it using Test::More or whatever. However, now I feel that trying to philosophise about the distinction between all those is not so useful for the people who are actually trying to write the tests. “Tests are good, mmkay? Just freaking write them!” chromatic has expressed some sentiments against the so-called “Behaviour Driven Development” (BDD) Domain-specific-languages (DSLs) such as cucumber here: http://modernperlbooks.com/mt/2012/04/what-testing-dsls-get-wrong.html One thing he says in a comment there is: <<<< Our clients are the parents, guardians, and teachers of children between the ages of eight and twelve inclusive. The intent of Cucumber is to make readable testcases, just as the intent of COBOL and AppleScript and visual component programming is to enable non-programmers to create software without having to learn how to program. >>>> Not only is it impossible to have people who are non-programmers write structure code without learning how to program (at least until we get sufficiently intelligent Sci-Fi-like AI that will be able to perform programming like humans do), I feel that you need to write some kind of code, however formatted, to write tests, just like HTML and CSS and spreadsheet programs, involve writing some kind of *code*. If you want to have your clients write tests, my best suggestion is to other instruct them in the proper methodology and discipline of coding, or alternatively have them show you how to reproduce the problem (using screenshots, screencasts, shared remote desktop sessions, etc.) and then *you* write a test for it.[Note] {{{ [Note] - some people fear that teaching laymen how to code will create competition for professional programmers, and dilute the profession. However, this is not true, because there's always a difference between a casual dealer in a craftsmanship or art, and someone who invested a substantial amount of time doing it. E.g: lots of people can cook well, but not everyone is a professional Chef. }}} So I think the distinction between the various tests may be useful for methodologists and software engineering researchers (people who try to guide other people how to code) more than the people who are actually coding. To quote Picasso: “When art critics get together they talk about Form and Structure and Meaning. When artists get together they talk about where you can buy cheap turpentine.” ( taken from http://orip.org/ ). Similarly, literature critics and researchers have very little to say that is of use for most writers and even authors. I hated studying Literature (what Americans might call "English" although naturally in Israel, we study Hebrew texts) with a passion, and didn't do too well on the tests (in part because I refused to write a lot of extraneous text, which the teacher seemed to have liked), only to become a writer of fiction and essays (see http://www.paulgraham.com/essay.html ) after graduation, which most people I talked with seem to have liked and appreciate what I wrote (although I admit they are certainly not letter perfect). Similarly, I'm now struggling with this tome - http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054 - which seems like I cannot see the forest for the trees from it, while I really enjoyed reading the much shorter and much more hands-on http://en.wikipedia.org/wiki/Test-Driven_Development_by_Example (by Kent Beck). The time we talk about how to write tests is often better spent writing tests (or production code, which is, naturally, what tests are aim to support and are meaningless without it), so I think we should just “freaking write them”. “Write tests, m*****f*****!” Regards, Shlomi Fish -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ Escape from GNU Autohell - http://www.shlomifish.org/open-source/anti/autohell/ Linux — Because Software Problems Should not Cost Money. Please reply to list if it's a mailing list post - http://shlom.in/reply .
