TDD is dead? Probably not :)

Just read an interesting post related to testing:

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

After reading it, for me, the thought that remained is that it says that unit-testing considering only units, trying to achieve 100% coverage is not the best approach to either test or design your APIs.

I agree with that: personally, I think test-driven/test-first development is something you should have in your cookbook (for me it's something I use mostly when I have something that's hard to reason about, so, first I go on to the create test-cases/fix test iteration until the final solution).

Still, when designing some system usually I reason more about interfaces (note: API interfaces not UI), so, the first thing I try to reason is what interface would be needed to do it, then I go on to implement it (although usually I do test-driven development for the API implementation), but then when that is stable, I create a system test integrating it to the actual application (so, for every feature there should usually be a system test accompanying it).

Also, I find that many times, having a system test first helps to speed up the process. I.e.: you want to open a project, create an entity, select some field and voila: a crash happens. So, the first thing I usually do is reproduce that scenario on a test and only then go on to try to reason about it (if your app has some macro system this can even be made very straightforward so that you can record a macro and just play it back on your test -- for instance, on Kraken which is a reservoir data processor I helped developing, having a macro system which writes the actual macro output as Python code helps a lot in writing tests... yes, it's hard to create a proper system like that, but in the end it's very useful for reproducing scenarios -- not mentioning that your users can automate their own scenarios). There are solutions such as Squish which also automate UI tests, but I must say I'm not very fond of that route (as your UI may change a lot and tests become brittle, but macros should be kept backward compatible regardless of that -- or at least give a reasonable error if something is no longer possible).

Sometimes if there's something very simple and straightforward, I may skip on testing, but as things become more complex, I find that system tests can't be skipped. Especially as programmers usually create things on layers (i.e.: you have to change something on a core library which will later be used in the UI layer somehow -- if you just did a unit-test in the core and mocked your way out for the UI you may break things and will only discover it if you actually had a system test).

Sure, I get that the test suite may get slower, but fortunately hardware has been keeping up -- also, it's important to make sure your tests can run in parallel in this situation, so, if you have an 8-core machine you can create 8 processes and just multiplex your test cases to run 8 times faster.

Some examples:

In Django this means I created a structure where I don't use the final database (which would be PostgreSQL), but use an in-memory SQLite, with just a few tests (properly marked to be run serially) to run in the 'real' environment and have a structure which creates only the tables I'll be accessing instead of all the tables... it has the benefit of failing if I somehow try to access a table that shouldn't be accessed and makes things faster and parallelizable -- this also means that Django test subcases with fixtures can't be used, but that's probably for the better (fixtures aren't usually needed -- just go on to programatically do what you must, even if that includes populating the db... that usually makes things better anyways). So, it may not be a complete application test, but it does system-testing feasible without having a test suite that becomes too slow.

In a Desktop app test suite some care has to be taken too... especially on tests that require focus (which have to be marked serial), but definitely, the UI has to be tested, so, I create functional tests which actually click buttons, write on line edits, check if buttons are disabled on situations, etc (but all programmatically, not through UI automation).

To sum it up, I agree with the main point which is that you don't need to do 100% coverage unit-testing mocking your way out to test a given unit, but I definitely don't think that TDD is dead: it's definitely something that must be in your toolbox, so that you can selectively choose when you want to use it... and regression testing is something you definitely can't skip. So, if you have a unit-test which would require mocking to much, don't let skipping that test bother you too much... but don't skip the system testing on that, and if unit-testing doesn't require mocking or huge setups, don't skip that either (unit-tests are usually a bit easier to debug when things fail).

In the end, as always, having things balanced is probably the best choice... no 100% TDD, no 100% system test but a healthy balance which helps catching errors before the user gets them but without becoming too burdensome for you team.

New toy

So, I've just upgraded to a new computer (a Lenovo z710). All in all a nice improvement.

This time I went for a bigger (17'') screen -- until now I was using a 15.6'' inches. My old computer is still working well, but it started to become way too noisy/hot for me (it was a Dell Studio 1558 -- and the fan became too dusty -- it's already a 4-years old computer and was never cleaned because to clean it I have to COMPLETELY disassemble it: take the keyboard out, screen, network connections -- really, the fan is THE hardest component to reach in this model).

So, after checking the net (and asking for a recommendation at http://www.reddit.com/r/SuggestALaptop/), I decided to go with the Lenovo z710... almost everything went Ok: it has a large back-cover which gives access to fans, memory, hard drive, so, cleaning it should be easier, 4 USB entries, a VGA port for an external monitor, 17'' 1080p, 16 GB of RAM, card reader, i7... there's only one problem so far, in which sometimes it won't turn on when only on battery (saw other complaints on the net about that too)... as I'm going to be mostly stationary, not that big of a problem for me (but it can be a dealbreaker for many).

So, first thing after getting the computer was changing the HD that came with it for an SSD. Really, this is not an upgrade that can be skipped if you're a software developer -- all your tools will be faster which is not only bound to make your life more pleasant, but also, it should pay for itself given your increased productivity.

Now, this was a huge stumbling block: it seems new computers don't have installation CDs with them anymore. No big deal I thought: just backup windows and restore in the new HD, but as it's smaller it was a no-go to. After other dead ends, what worked for me was putting the new HD in a USB HD case, getting http://www.easeus.com/ and doing a clone from one HD to the other. It's incredible how Microsoft/Lenovo managed to do something which should be very simple and straightforward (upgrading an HD) such a difficult thing (thankfully EaseUS TODO Backup made it much simpler -- provided you have a USB HD case lying around). I'll make sure I have a backup with everything configured there so that I don't risk loosing my Windows installation if some day the HD becomes trash.

Also, the computer came with Windows 8.1, which does seem a nice OS (my previous one had Windows 7). The only thing is that it does require quite some amount of customization to be usable... the start screen is really as bad as people say, but Windows 8.1 can be customized to boot directly to the desktop, so, I almost never see it. Also, Lenovo came with http://www.pokki.com/windows-8-start-menu, which I didn't know about, but seems a worthwhile replacement for the old Windows 7 start menu (so, I'm not really missing it thanks to pokki -- but I'd be considering going back to Windows 7 if it wasn't for it).

After that it was mostly a deal of getting my development environment in place and up to date (i.e.: TCC, Eclipse, LiClipse, Notepad++, Chrome, FTP, putty, pageant, plink, Git, Java, Python, VirtualBox, etc, etc). It does take a 1-2 days of work for me to set everything up -- but if the setup does hold for 4 more years, that's not so much in the end... time will tell :)

In the end, I'm really happy with the new toy!

Why?

So, I've just created a new blog for me... why?

Well, I do have other blogs such as http://pydev.blogspot.com and http://liclipse.blogspot.com, but they're very targeted towards specific products and I was missing a place I could write about things which are more general (although mostly about technology and software, many things may be off-topic here).

All in all, a new place to write about anything I want :)