
Less thinking. More testing. - chrismealy
http://stevereads.com/weblog/2010/05/22/less-thinking-more-testing/
======
xenophanes
> I no longer trust long chains of reasoning from seemingly self-evident low-
> level principles.

The correct principle is not to "trust" long chains of reasoning which one
doesn't understand in their entirety, especially ones with strong conclusions.
The problem here isn't long chains of reasoning (we could hardly do without
any of those), but rather failure to hold them to high standards in how
understandable they are, and failure to put in the effort to understand the
whole thing before accepting it.

~~~
randallsquared
Quite often a person believes they understand something when they don't. In
this case, no amount of exhortation to understand the chain of reasoning will
help. Unfortunately, I think there's a false dichotomy here; you have to
understand the problem well enough to write useful tests, and if you don't
understand a failure mode, you're probably not going to write anything to test
it.

------
joubert
I had a thought along the following lines: if I have test cases for a feature,
it would be really cool if I have an engine which can figure out code to
satisfy thoses tests. I.e. I define the contract; the computer figures out how
to solve. Kinda like Simonyi's intentional programming. Is anybody working on
something in this area?

~~~
GeoffWozniak
I did a thesis that explored aspects of generating code that passed tests, but
it was limited to deriving adequate structural representations based on
behavioural specifications.

Two approaches were shown: changing data structure representations to meet
requirements and generating class structure/hierarchy. The thesis showed that
it is possible to do this and how to do it, but it is a huge topic.

If you're interested, I'll put more effort into making my thesis available
online in HTML format. In the meantime, you can get it in a variety of places.

[http://duckduckgo.com/?q=Structuring%20Data%20via%20Behaviou...](http://duckduckgo.com/?q=Structuring%20Data%20via%20Behavioural%20Synthesis)

Incidentally, generating behavioural elements (like entire functions) to pass
tests would be very difficult although I have been toying with ways to try it
out.

------
10ren
Because this article covers a lot of ground, it really struck me that the term
_testing_ is ambiguous: it can mean _unit-testing_ or _user-testing_.

In prototyping _sprints_ , TDD seems to acknowledge that unit-testing slows
you down and creates rigidity, and therefore encourages you to just get the
basic thing working without unit tests. You can throw it away, or
fundamentally change the outcome, or the architecture, or the structure of the
code. _User-testing_ is how you test a prototype (including just playing with
it yourself).

But in building a codebase that you will live with for sometime, that will be
built-on and modified and bug-fixed and tweaked, _unit-testing_ becomes really
helpful.

------
stretchwithme
creating a situation where users are separated into two different groups and
then making a single variable different for each groups can indicate the
effects of the variable given a large enough group size

but taking that experience and applying it to history where many things are
changing and where you cannot separate everyone into 2 different groups will
not necessarily tell you anything about one arbitrarily selected variable.

------
delano
"Talk doesn't cook rice."

