Hacker News Reader

Comment by morganherlocker | Hacker News Reader

Often times I find large static code bases to be lacking tests. When you have type safety, the tendency is to test less, and in many organizations, forgo testing entirely. A dynamic language will force you to write tests a lot sooner, before the whole codebase turns into a bad game of jenga. In my experience, testing seems to be a lot easier in a dynamic language as well.

I would say that the most stable codebase would be a static one with lots of tests, but I would also guess that this would be the slowest to develop, and would be the most difficult to implement in a real world team of developers.

I know most of us would balk at a huge codebase with zero tests, but it happens all the time. I would definitely prefer a dynamic code base in which I could get my team to write decent tests, but give up type safety, than to have type safety at the cost of decent tests.

View on HN

Static typing lets you focus on testing behaviour rather than "forcing" you to test something that machine can figure out for you.

The type checking is a form of unit test. The compiler just does it for you automatically.

At least in Haskell, which encourages writing pure functions, testing is easier. Also, QuickCheck can use static types to make tests more concise and cover more ground more quickly.

What research exists that testing actually is worth it? I feel like people seem to take it for granted and speak about personal experience and personal values but I never read about any actual convincing research that shows TDD as actually being beneficial. It's more like a cargo cult: Write tests and things will be well.

What alternative do you propose, and what "actual convincing research" shows that your approach is actually beneficial?

In the context of software engineering approaches, "What research exists?" is basically a conversation killer of a question. The scientific method, when applied to medium-number, complex-interaction systems like most business settings, offers very little in the way of predictive power. At best, it may illuminate some dynamics and raise some questions to ask, but rarely predict the future in the way that hard sciences research does. This is why, if you a predisposed to label something like TDD as "cargo cult", you will likely never find any published research to be "convincing".

But that said, a simple search for "published tdd research" turns up quite a few hits, including this one from Microsoft right at the top: http://research.microsoft.com/en-us/groups/ese/nagappan_tdd....

It seems you are conflating testing and TDD, they are different things.

However the benefits of testing can seem rather obvious if you are in the software industry. We hire people to do QA, and if the developers write tests, we can hire fewer people to do QA and still meet reliability targets. Software development is a loop: design -> code -> test, over and over again, and automated testing means that the code is still fresh in your mind when you fix it.

But it sounds like you're wondering, "why test at all?" Well, would you sell a car or a table saw that had never been tested to a customer?

What do you need research for? If you don't test your code, how do you know it works, at all? Obviously you do test it, so why not have those tests written in code, so they can be repeated at any time and catch regressions? The benefits are entirely obvious.

> What research exists that testing actually is worth it?

It's absolutely not worth it. By the way, I have a codebase with 240k line of early 2000's guaranteed-untested PHP, coded by the best and brightest and complete with best-of-breed programming practices such as global variables I could maybe interest you in. I also have a full complement of bridges available.

> I never read about any actual convincing research that shows TDD as actually being beneficial.

TDD? That's probably good when you know what you are doing, but I must admit I'm a "test after the fact" man most of the time. Probably because I don't know what I'm doing most of the time :)

> I would say that the most stable codebase would be…

Why guess, when you can look at real examples?

Look at standards like MISRA C, or projects like the computers on the STS or Mars rovers. Using a static type system and testing things is but a small part of the process typically used for high-reliability systems.

> the process typically used for high-reliability systems.

And that's the key. Producing high quality systems is something that is emergent out of a process designed to produce high quality systems (and in fact, you need to have a process for improving the process). What is your process? Has it gone under rigorous examination with an eye towards output quality? Then any quality that results is a happy accident of competent engineers and a particular time and place.

Unit tests, types, are simply a small part of how quality is created.

Reply on news.ycombinator.com