HN user

hjwp3

34 karma
Posts1
Comments30
View on HN

Maybe in context it's not so bad?

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.

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...

In fact, non-Python developers are welcome too. You can just use the site for hosting your repos, be they full of ruby, node.js, haskell, or whichever Lovecraftian horror of a language you prefer... Just make sure to click on "Bash console", and not on any of those terrible Python ones...

TDD django Tutorial 14 years ago

I don't think I accept your critique then - I make a clear distinction between "functional" tests (ie, the selenium ones), and "unit" tests, and I write both types

Although you may have a valid point that my "unit" tests aren't unit-ey enough to be called real "unit" tests, because they rely on django and the database - but I still think they serve the correct purpose.

Whatever you call them, they very clearly are written first, before any lines of code, and each line of code is only written in order to fix a failing test.

Maybe you're saying that if my "unit" tests aren't "unit-ey" enough, becauye they are too reliant on Django and the database, they don't work so well in the sense of test-driven design? If so, how?

Let's look at a specific example, ie how to design a model for Polls.

my approach, in pseudocode:

  instantiate a model
  assign some attributes to it
  save it
  retrieve it from the database
  assert the retrieved object has the attributes assigned earlier, with the correct values & types (including a datetime value)
a more "unit" approach:
  instantiate an object
  assert it is a subclass of django's model types
  assert it has default attributes with correct default types
  finally, use some django voodoo or metaclass inspection to confirm that the datetime field, whose default value is "None", is actually a working datetime field...
That last bit is the clincher - in this case, I think particularly due to the datetime field, using a more "unitey" approach actually makes it /harder/ to use TDD to design the object... Whereas using my approach makes it very natural - the test influences the design, because the test uses the object in the way that the code will, the test is a client of the final objects' API, in a more complete way than a "true" unit test would be...

So, I think in this specific case, making tests "more unit-ey" wouldn't help make for better test-driven-design.

I do accept the point that if you're tests aren't isolated from one another, then it's very hard to refactor one area of code without breaking lots of tests in other areas. And I think that where it's my own code, I'm very prepared to spend effort isolating unit tests from each other, using Mocks or whatever else. But when it's Django code, which has a stable API, I'm not that worried by exercising it in unit tests...

TDD django Tutorial 14 years ago

I can totally see your objection re the tests not being "unit-ey" enough... But why would you say it's not TDD?

TDD django Tutorial 14 years ago

Hi there, author here, and thanks - that's all very valid feedback.

I totally accept the point on the first few "unit" tests being reliant on the database. I took the decision that testing behaviour, and thus introducing the Django ORM early on, would be better in terms of what the students are learning... I think that a discussion of how you could re-write those tests without using the database, perhaps in a later tutorial, would definitely be a good idea, and it could then take in some of the pros and cons of making things maximally granular...

I spend a bit of time later on discussing "testing philosophy", ie what to test and what not to test - I'd be interested in your feedback on that?

http://www.tdd-django-tutorial.com/tutorial/3/

Also, I'd tend to agree that testing model attributes is a bit OTT - it's very close to testing a constant... but, it really doesn't take that long, and if it provides a scaffold that makes it easier to write future unit tests on the model (eg, on a computed field), so much the better for a little nudge that encourages more test coverage...

thanks!

re: the first unit test, and the saving & retrieving of records -- i know this feels a bit like "testing django", but the real intention is to test that we've set up our model with the right fields.

The alternative would be to test defaults - instantiate a model, and assert that it has attributes with the correct names for the model fields we've defined, and the correct default values... I suspect that is the more common pattern, and it's certainly what we do at work. I think it can be seen as better in the sense that it has less of a dependency on Django. OTOH, the saving and retrieving provides a useful introduction to the ORM, so it's useful for the wider tutorial. It's also a bit more in the spirit of testing desired behaviour... So, pros and cons on each side really...

thanks for the feedback - am not mad good at the old graphic design, but it's all too easy to just say "I can't be bothered with that stuff"... I'll try and make some improvements. I gather it looks particularly ugly on windows, must take a look...

We're definitely keen to get it in asap. The hang-up was getting secure websockets working - that was showing up a bunch of socket errors server-side, but the latest dev testing seems to show things are looking better, so we hope to get it in real soon. weeks not months...

OK that link totally didn't do what I thought it would. Anyways, what I meant to say was: see Tycho's post below - sometimes you're at a PC which doesn't have Python installed.

So it doesn't have to be a replacement for your desktop, although it can be. It can also just be a complement - if you use dropbox or github, then you can know that, no matter where you are, you can always get to your code and work on it... internet cafe in Thailand, friend's PC, locked-down-corporate-desktop...