Shlomi Fish
2013-01-26 09:13:14 UTC
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
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 .
-----------------------------------------------------------------
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 .