First of all: avoiding factory farm meat doesn’t necessarily mean eating non-factory farm meat. You can also not eat meat, or simply eat much less than whatever you’re eating now (which is what the author encourages you to do). Isn’t that cheaper in most places anyway? If so, that would actually help your economy :-D

And yeah, you can say that “people just want to eat meat”, but then the problem is not price :-)

Also, even if there are a lot of people that couldn’t afford not eating factory farm meat, there’s a HUGE amount of people that can. I don’t think the point is that everyone has to do it, simply that the more, the merrier :-)

All that said, I also fear that the only way to make this change might be some kind of huge crisis :-(

I agree that the status quo is insane, but I don’t think that a handful of [relatively] well-off people going out of their way to avoid eating factory farmed food is going to change anything, besides how good those people feel about themselves. The only way that things will change, in my opinion, is if there is a massive global war, or an epidemic of the sort of disease that you mention. A third possibility is that world leaders will enforce a global population reduction – unlikely, but I would probably prefer that solution over the other two.

Thanks for the link, I didn’t know that style of testing. It reminds me a bit of the idea behind fuzzers (which I have never used myself), but more on the structured side.

The last point was the least thought out, and I think that shows. After a bit of feedback and thinking, my conclusion is that the part that bothers me the most is having testcases calculate the expected values (in a non-trivial way). That makes the test code not easy to follow (bad), and you can easily introduce bugs in the code calculating the expected values (terrible), so it’s hard to know what is wrong when some test fails. Which is maybe something similar to the tool you’re linking, but done by hand and extremely error prone.

Regarding your addendum “trying to cover all cases in the tests”. I agree with that unit tests and functional tests should test a few good cases instead of _as many as possible_, because one of their goals is to specify the behaviour with examples.

I thought it could be an interesting complement to mention a slightly different way of testing a system that exercises many more cases, that you get by using something of the style of scalacheck (http://code.google.com/p/scalacheck/). Here the writter of the test specifies the properties of the system and the tool generates the examples.

This is much slower, obviously (part of the point is that the tool can generate hundreds, or any number of examples) but, although I must admit that I haven’t used it for a real project, I think it could be an useful complement, particularly when the thing that is interesting to test is very hard to separate from the data (eg machine learning)

I suggest Emacs Starter Kit.

You might also enjoy ‘Vimgolf in Emacs’ by Tim Visher

indy, thanks for the tip, I’ll have a look.

You should check the links to hippie-expand and iy-go-to-char, they are relative to your site.