> On the Merits of Trivial Tests for Trivial Functions
> In the short term it may feel a bit silly to write tests for simple functions and constants.
> It’s perfectly possible to imagine still doing “mostly” TDD, but following more relaxed rules where you don’t unit test absolutely everything. But in this book my aim is to demonstrate full, rigorous TDD. Like a kata in a martial art, the idea is to learn the motions in a controlled context, when there is no adversity, so that the techniques are part of your muscle memory. It seems trivial now, because we’ve started with a very simple example. The problem comes when your application gets complex—that’s when you really need your tests. And the danger is that complexity tends to sneak up on you, gradually. You may not notice it happening, but quite soon you’re a boiled frog.
> There are two other things to say in favour of tiny, simple tests for simple functions.
> Firstly, if they’re really trivial tests, then they won’t take you that long to write them. So stop moaning and just write them already.
> Secondly, it’s always good to have a placeholder. Having a test there for a simple function means it’s that much less of a psychological barrier to overcome when the simple function gets a tiny bit more complex—perhaps it grows an if. Then a few weeks later it grows a for loop. Before you know it, it’s a recursive metaclass-based polymorphic tree parser factory. But because it’s had tests from the very beginning, adding a new test each time has felt quite natural, and it’s well tested. The alternative involves trying to decide when a function becomes “complicated enough”, which is highly subjective, but worse, because there’s no placeholder, it seems like that much more effort, and you’re tempted each time to put it off a little longer, and pretty soon—frog soup!
> Instead of trying to figure out some hand-wavy subjective rules for when you should write tests, and when you can get away with not bothering, I suggest following the discipline for now—as with any discipline, you have to take the time to learn the rules before you can break them.
So, we write tests to deal with complexity, but we are also writing tests for trivial things because.. something something ninjas.. something something discipline..
So what's this got to do with selling TDD? You can write "placeholder" tests afterwards just as easily..
I recently went through a bit of a comparison exercise myself, after my Sony Vaio Z series packed in. I had a slightly higher budget than OP because I wanted something reasonably high-end, able to run several VMs for example, but nice and portable. So, in case anyone else finds it useful:
- probably the most sensible choice would have been a fully specced-up Galago from System 76: 16GB ram, core i7, space for two (!) SSDs, etc etc. On the pure specs, it's the clear winner -- it's practically impossible to find an i7 in 13 inches with 16 gigs of RAM. And it's great to support a Linux-friendly company. One minor problem was that I do occasionally need Windows (for Powerpoint), but I guess I could have installed it. The real reason I didn't go for it (and I'm about to betray a character weakness here) is that I saw it in real life and... I thought it was too ugly. Didn't suit my vanity. And I couldn't get on with that weird screen hinge. Still, my mate Hansel wrote an excellent review of the Galago, check it out here: http://aychedee.com/2014/01/04/galago-ultrapro-review/
- the other sane choice would have been a thinkpad. As this thread overwhelmingly proves, they have an excellent reputation, and should work well under Linux. My dad has one, and I can confirm that they feel really well built, and are nice and light. Only real tech problem is the X240 is limited to 8GB. That and the seriously weird touchpads, which depress down about 5mm with a big ker-chunk, they feel like they were designed for use by children on a button-bashing arcade machine to launch nukes or something. But I can imagine getting used to them. Also briefly considered getting an X230 off ebay, because 16GB, but screen resolution was seriously weak.
- another option would have been a Dell. They have a good rep, and good linux support, but the XPS13 suffers from the same problem of the 8GB limit, and the XPS15 was too big -- a friend of mine tells me it feels a little heavy, and that the lid feels a bit feeble -- so the build quality isn't as good as the thinkpads. The 15 would be a good option for someone prepared to carry something a little heavier tho, 16 gigs and excellent resolution.
- at this point I started casting around for other solutions, and in the end I did something completely irrational. I came across the Samsung Ativ Book 9 Plus, and despite its stupid name I kinda fell for it. So I've impulse-bought one on ebay for about $1000 (new). And this despite the fact that Ubuntu is absolutely not ready for HiDPI screens, and that all the info on getting Linux installed on them sound like it's a nightmare, and that it's just never going to work. But, heck, I feel like Linux on the Desktop is meant to be hard, and not quite work. And it's SO SHINY! http://www.mobiletechreview.com/notebooks/Samsung-ATIV-Book-...
Thanks! We were thinking it would be useful for people posting solutions to stackoverflow questions, and also maybe people doing remote-pair-programming, as a way of sharing code with an interactive terminal to work through ideas... Or perhaps for people writing tutorials...
> On the Merits of Trivial Tests for Trivial Functions
> In the short term it may feel a bit silly to write tests for simple functions and constants.
> It’s perfectly possible to imagine still doing “mostly” TDD, but following more relaxed rules where you don’t unit test absolutely everything. But in this book my aim is to demonstrate full, rigorous TDD. Like a kata in a martial art, the idea is to learn the motions in a controlled context, when there is no adversity, so that the techniques are part of your muscle memory. It seems trivial now, because we’ve started with a very simple example. The problem comes when your application gets complex—that’s when you really need your tests. And the danger is that complexity tends to sneak up on you, gradually. You may not notice it happening, but quite soon you’re a boiled frog.
> There are two other things to say in favour of tiny, simple tests for simple functions.
> Firstly, if they’re really trivial tests, then they won’t take you that long to write them. So stop moaning and just write them already.
> Secondly, it’s always good to have a placeholder. Having a test there for a simple function means it’s that much less of a psychological barrier to overcome when the simple function gets a tiny bit more complex—perhaps it grows an if. Then a few weeks later it grows a for loop. Before you know it, it’s a recursive metaclass-based polymorphic tree parser factory. But because it’s had tests from the very beginning, adding a new test each time has felt quite natural, and it’s well tested. The alternative involves trying to decide when a function becomes “complicated enough”, which is highly subjective, but worse, because there’s no placeholder, it seems like that much more effort, and you’re tempted each time to put it off a little longer, and pretty soon—frog soup!
> Instead of trying to figure out some hand-wavy subjective rules for when you should write tests, and when you can get away with not bothering, I suggest following the discipline for now—as with any discipline, you have to take the time to learn the rules before you can break them.