5 ms·

I am glad you put automated tests as one of the first ones. To this date I find that many people - often mid level, and sometimes senior developers - are very u

I am glad you put automated tests as one of the first ones. To this date I find that many people - often mid level, and sometimes senior developers - are very uncomfortable with autmated tests. As a result they don't use this tool, and end up being less productive, and often write more complex than needed code - and of course code with more bugs that could have been avoided. I'm no TDD or automation advocate - however I do see that this tool is essential to modern software development, and the only way to learn to use it, is by practice. I would encourage every engineer who's covered the basics to go full-in on TDD with 100% test coverage for a few days or weeks. Not because it will make you more productive or less bugs (you will be less productive), but it will change your thinking of writing code (similar to how learning Lisp will have a massive impact on your thinking of structuring code). TDD + 100% coverage is an extreme, which is worth experiencing to take learnings from it. Later down the road, when you've gotten into the habit of developing with no, or barely any automation, it will be much more difficult to learn to fit this tool into your coding routine.

cm3 10y ago
TDD can be tedious at times, but if you do it, you quickly reap the benefits. It makes testing easier, it reassures you that you didn't break everything completely with a random change, and it keeps your API in check. And it makes more of the process reproducable.
- mbrock 10y ago
  TDD is a kind of semi-formal specific process with a whole legacy of consultant workshops and all of that stuff. So I think it's great to mostly ignore that, since it's contentious, and focus on that core question: how do I know that the system works correctly? This also makes it obvious why type systems are a glorious ally, in addition to test suites and proofs. And it's a core question because if I don't have grounded confidence in the system's correctness, then that's likely to be anxiety-inducing, irresponsible, and sometimes dangerous.
  - cm3 10y ago
    Right, and I didn't learn TDD formally. Sorry for using it freely. I write tests in tandem with the implementation and do not write tests and only then the implementation.
    - ahstilde 10y ago
      When I knew exactly my code's requirements, I wrote the tests first. I was writing an interpreter. Tests-first was a smart move.
      - couchand 10y ago
        I find writing tests first really helps me sort out the requirements if I'm unclear about them.
yoodenvranx 10y ago
> however I do see that this tool is essential to modern software development If we are talking about the later stages of the life of a software project then I completely agree with you. But if you just started a new project and you are still in a constant state of change then a large test suite will slow you down because you have to adapt all your tests all the time. In the worst case you might even stop to improve your software just because updating your tests is too much work.
- mbrock 10y ago
  Unfortunately, it's difficult to pinpoint the time to abandon that initial flexibility and create a test suite. Moreover, creating that test suite after the project has grown is likely to be tedious, too... and often requiring serious refactoring to accommodate testing practices. The XP folks were always all about changing requirements and flexible code, and unless they're all deluded, it's not true that testing necessarily hampers a new project.
  - lowmagnet 10y ago
    When I start a new maven project, it comes with junit by default and with the test tree created. The first thing I do when starting a nontrivial class is to hit the shortcut for create new test. I should make it fail empty classes in the test tree. Automating the testing burden helps especially when interfacing with a tricky API; sometimes it's mocking, sometimes it's a real object in isolation.
- mooreds 10y ago
  > But if you just started a new project and you are still in a constant state of change then a large test suite will slow you down because you have to adapt all your tests all the time. I have been in a new project where progress was slowed by all the tests. But the issue I have with "I will write tests later, after things have stabilized" is that, in my experience, that day never comes. There is always a feature that would add value, or some fire to be put out. Of course, you could arbitrarily pick a date or time to start testing, but as some one who was responsible for a smallish code base (30k lines, maybe 2-3 man years) with no tests, I can tell you that it is hsrd to start that. You have to either start testing when building a new piece of software (which is easy, but you really want to have assurances about the working of your existing code), or try to apply tests to previously untested code, in which case you are unraveling quite a bit of complexity and possible untestable/difficult to test constructs.
crottypeter 10y ago
Automated tests are very important but source control is an order of magnitude more important IMHO. I hope its omission is because OP thinks it goes without saying. It doesn't though, just the other day I read on HN that people have colleagues who don't use any source control.
- mooreds 10y ago
  Absolutely. Using source control is like using an editor.
a_imho 10y ago
>Later down the road, when you've gotten into the habit of developing with no, or barely any automation, it will be much more difficult to learn to fit this tool into your coding routine. Don't agree, imo a good automation service is abstract enough that it can be hooked into your cycle or at least appended to it. Automated tests and CI is a prime example. I'm ready for the down votes, but the most important aspect of TDD is job interviews (or blog posts), telling others you do it even at home on your pet project is a big plus somehow. My guess it is the best way to communicate you care about quality, even if equating the two is obviously a half truth. Again Norvig vs. Jeffries tells me practices go a shorter way than actual practicing and ability.
kabdib 10y ago
Automated tests are great. Can't imagine not having them. Automated test systems, in my experience, have sucked pretty hard. Often written by Q/A engineers frustrated at not being "real" engineers [yeah I know, toxic culture], and just not written well. Like the test systems I could never install on my workstation or even get running on my own, in order to reproduce problems and debug them. Or the systems that would assign "Priority 0 wake-up-in-the-middle-of-the-night" issues to failures in the test framework itself. Test frameworks are best kept as simple as possible; be wary of architecture astronautics. I like the "TDD is nice, use it when it's useful" attitude. TDD as a tyranny works about as well as any other silver bullet we've seen in software development over the years (that is, not very well).
- komali2 10y ago
  Off-topic, but I've always felt like "silver bullet" isn't a very good metaphor to use because we keep using it sarcastically, as above. Wasn't the silver bullet the only way to stop a werewolf? Or does the phrase come from somewhere else? Anyway maybe something like magic bean or some other "looks useful but turned out not to be" metaphor would be better, not sure which one though.
  - kabdib 10y ago
    "Silver bullet" was popularized (if not coined) by Fred Brooks in _The Mythical Man-Month_, and since that book is pretty widely read, the term is well understood. It's definitely sarcastic, but that doesn't mean it's not accurate. [Depending on your mythology, you can kill a werewolf with a silver sword, and probably other silver objects. Poul Anderson has an interesting treatment of werewolf vulnerabilities in his collection _Operation Chaos_]
maxxxxx 10y ago
Automated testing is a learned skill. You need to develop your toolbox how certain things can be automated. It's a lot of work learning but once you have a decent system and know how to design things right for automation it's super valuable. In my current job we do a lot of automated testing and it took me several years to get my head around it and design things in way they can be automated.
hobolord 10y ago
where does one begin with automated testing? I realize it's importance after reading countless posts about it, but for the most part to me it seems like a lot of work is required to design the system that will perform the automated testing, depending on the complexity of your project

cm3 10y ago

TDD can be tedious at times, but if you do it, you quickly reap the benefits. It makes testing easier, it reassures you that you didn't break everything completely with a random change, and it keeps your API in check. And it makes more of the process reproducable.

mbrock 10y ago
TDD is a kind of semi-formal specific process with a whole legacy of consultant workshops and all of that stuff. So I think it's great to mostly ignore that, since it's contentious, and focus on that core question: how do I know that the system works correctly? This also makes it obvious why type systems are a glorious ally, in addition to test suites and proofs. And it's a core question because if I don't have grounded confidence in the system's correctness, then that's likely to be anxiety-inducing, irresponsible, and sometimes dangerous.
- cm3 10y ago
  Right, and I didn't learn TDD formally. Sorry for using it freely. I write tests in tandem with the implementation and do not write tests and only then the implementation.
  - ahstilde 10y ago
    When I knew exactly my code's requirements, I wrote the tests first. I was writing an interpreter. Tests-first was a smart move.
    - couchand 10y ago
      I find writing tests first really helps me sort out the requirements if I'm unclear about them.

yoodenvranx 10y ago

> however I do see that this tool is essential to modern software development If we are talking about the later stages of the life of a software project then I completely agree with you. But if you just started a new project and you are still in a constant state of change then a large test suite will slow you down because you have to adapt all your tests all the time. In the worst case you might even stop to improve your software just because updating your tests is too much work.

mbrock 10y ago
Unfortunately, it's difficult to pinpoint the time to abandon that initial flexibility and create a test suite. Moreover, creating that test suite after the project has grown is likely to be tedious, too... and often requiring serious refactoring to accommodate testing practices. The XP folks were always all about changing requirements and flexible code, and unless they're all deluded, it's not true that testing necessarily hampers a new project.
- lowmagnet 10y ago
  When I start a new maven project, it comes with junit by default and with the test tree created. The first thing I do when starting a nontrivial class is to hit the shortcut for create new test. I should make it fail empty classes in the test tree. Automating the testing burden helps especially when interfacing with a tricky API; sometimes it's mocking, sometimes it's a real object in isolation.
mooreds 10y ago
> But if you just started a new project and you are still in a constant state of change then a large test suite will slow you down because you have to adapt all your tests all the time. I have been in a new project where progress was slowed by all the tests. But the issue I have with "I will write tests later, after things have stabilized" is that, in my experience, that day never comes. There is always a feature that would add value, or some fire to be put out. Of course, you could arbitrarily pick a date or time to start testing, but as some one who was responsible for a smallish code base (30k lines, maybe 2-3 man years) with no tests, I can tell you that it is hsrd to start that. You have to either start testing when building a new piece of software (which is easy, but you really want to have assurances about the working of your existing code), or try to apply tests to previously untested code, in which case you are unraveling quite a bit of complexity and possible untestable/difficult to test constructs.

crottypeter 10y ago

Automated tests are very important but source control is an order of magnitude more important IMHO. I hope its omission is because OP thinks it goes without saying. It doesn't though, just the other day I read on HN that people have colleagues who don't use any source control.

mooreds 10y ago
Absolutely. Using source control is like using an editor.

a_imho 10y ago

>Later down the road, when you've gotten into the habit of developing with no, or barely any automation, it will be much more difficult to learn to fit this tool into your coding routine. Don't agree, imo a good automation service is abstract enough that it can be hooked into your cycle or at least appended to it. Automated tests and CI is a prime example. I'm ready for the down votes, but the most important aspect of TDD is job interviews (or blog posts), telling others you do it even at home on your pet project is a big plus somehow. My guess it is the best way to communicate you care about quality, even if equating the two is obviously a half truth. Again Norvig vs. Jeffries tells me practices go a shorter way than actual practicing and ability.

kabdib 10y ago

Automated tests are great. Can't imagine not having them. Automated test systems, in my experience, have sucked pretty hard. Often written by Q/A engineers frustrated at not being "real" engineers [yeah I know, toxic culture], and just not written well. Like the test systems I could never install on my workstation or even get running on my own, in order to reproduce problems and debug them. Or the systems that would assign "Priority 0 wake-up-in-the-middle-of-the-night" issues to failures in the test framework itself. Test frameworks are best kept as simple as possible; be wary of architecture astronautics. I like the "TDD is nice, use it when it's useful" attitude. TDD as a tyranny works about as well as any other silver bullet we've seen in software development over the years (that is, not very well).

komali2 10y ago
Off-topic, but I've always felt like "silver bullet" isn't a very good metaphor to use because we keep using it sarcastically, as above. Wasn't the silver bullet the only way to stop a werewolf? Or does the phrase come from somewhere else? Anyway maybe something like magic bean or some other "looks useful but turned out not to be" metaphor would be better, not sure which one though.
- kabdib 10y ago
  "Silver bullet" was popularized (if not coined) by Fred Brooks in _The Mythical Man-Month_, and since that book is pretty widely read, the term is well understood. It's definitely sarcastic, but that doesn't mean it's not accurate. [Depending on your mythology, you can kill a werewolf with a silver sword, and probably other silver objects. Poul Anderson has an interesting treatment of werewolf vulnerabilities in his collection _Operation Chaos_]

maxxxxx 10y ago

Automated testing is a learned skill. You need to develop your toolbox how certain things can be automated. It's a lot of work learning but once you have a decent system and know how to design things right for automation it's super valuable. In my current job we do a lot of automated testing and it took me several years to get my head around it and design things in way they can be automated.

hobolord 10y ago

where does one begin with automated testing? I realize it's importance after reading countless posts about it, but for the most part to me it seems like a lot of work is required to design the system that will perform the automated testing, depending on the complexity of your project