1. 23
  1.  

  2. 5

    I’m confused. Are we just talking about writing tests before your features or not writing tests at all? This post has examples of both.

    In general, I never want to work for a company again that doesn’t have unit tests on all their major services. Testing in general is crucial and vital to be able to refactor things quickly and move platforms and technologies quickly. There is no substitute for good, automated regression tests. If your tests miss something, you can add a test. If you get a false negative, you can fix/improve the tests.

    I prefer writing tests first, but it depends on the problem. If it’s a totally new subsystem, you may need to write a few prototypes and figure out how you want to architect it first. Then write your tests. If it’s building into an existing system, it’s usually easier to write the tests first and red/green them. It depends on the problem. But you should always have tests.

    The post mentions the Linux kernel. It’s more difficult when you need to test with different hardware, but a quick search led to me several independent projects by other companies to at least build some basic automated tests around the Linux kernel. So they do exist, even if not ever kernel developer uses them.

    1. 2

      Linux doesn’t have continuous integration so the few tests that it has are not very useful.

    2. 3

      I once spent three hours trying to debug a broken TLA+ spec, eventually finding that I mixed up => and =>.

      Huh?

      Every organization has a QA department.

      This is outright false. I’ve worked for many that didn’t. Often they produced better software.

      Regardless of how you approach correctness, it’s definitely worthwhile to do some design in advance.

      Citation needed for this part - the author has an anecdote, but it doesn’t match my experience.

      1. 12

        Huh?

        It was actually \s\s=> and \s=>, but my markdown renderer removed the spaces, which I think is actually pretty funny.

        This is outright false. I’ve worked for many that didn’t. Often they produced better software.

        That’s Eric’s quote, not mine :P

        Citation needed for this part - the author has an anecdote, but it doesn’t match my experience.

        Making Software has a chapter called “Architecting: How Much and When”, which is a really good literature review. It has a lot of data, but the overly simplified version is that for a 10 KSLoC project, the sweet spot is about 5% time designing in advance, gradually rising to 20% for a 100 KSLoC project. So for most tasks that you estimate as taking a couple of days, it’s probably worth spending half an hour planning it out before you start coding.