Should programming languages support unit testing natively?

http://beust.com/weblog/archives/000522.html

by fogus • 17 years ago

16 22 17 years ago

derefr• 17 years ago

I've always thought the unit test[s] for any given method in a system should be accessible at runtime as a singleton-method of the method object/closure. It would be a similar idea, in effect, to Lisp docstrings, except with another closure in place of a string.

mark_h• 17 years ago

Not quite a singleton method, but python does have tests embedded in doc-strings: http://docs.python.org/library/doctest.html

omouse3• 17 years ago

No, they should support contracts as Eiffel does or have better type systems as Haskell has. Most problems can be eliminated by making them impossible in the first place ;)

j_baker• 17 years ago

The problem is that this frequently turns into a case of throwing the baby out with the bathwater. I like languages where I spend less time fighting the compiler and more time coding. If tests are the price I have to pay, then so be it.

mustpax• 17 years ago

And ironically enough, it ends up being easier to write test harnesses with dynamic languages because it is easier to mock things up.

With languages like Java, the inherent rigidity requires all sorts of ugly ugly reflection hacks, and factory, impl, interface proliferation to get the flexible testing behavior you get for free with more dynamic languages.

If you need to add new language primitives to make unit testing practical, maybe your language is too cumbersome.

omouse3• 17 years ago

So you prefer banging out a lot of code to thinking before coding?

jlouis• 17 years ago

In Eiffel you do not fight the compiler. The idea is that you define a set of assertions that must be true before writing the code. This process strengthens the program as you get a more well-defined knowledge of who-does-what in the program. This "Design by Contract" behaviour is much like TDD/BDD.

In Haskell, you do not fight the compiler either. With practice, you will find that the few type errors the compiler returns to you are legitimate: Wrong calling conventions, typos, API misuse, returning nonsense in a specific case and so on. I have, perhaps, some 5 errors per 100 lines of Haskell code I write that the compiler quacks on. It is equally bad moving dynamically typed programming idioms to Haskell as it is moving statically typed programming idioms into, say, Python.

txxxxd2• 17 years ago

But what if there's a bug in your contract?

omouse3• 17 years ago

Then there's a bug in your thought process. It's easier to fix a contract than to fix the N unit-tests which basically spell out that same contract :|

cabalamat2• 17 years ago

Unit tests shouldn't be part of the language, but they should be part of the standard library.

clutchski• 17 years ago

agreed. i'd also add a native assert statement allows for very clean test cases.

cabalamat2• 17 years ago

I agree that assert statements are good.

The language should be flexible enough that you can write them in the language, and not have to rely on the language providing them.

gregfjohnson• 17 years ago

I agree that tests should be part of the language. For example it would be great to have convenient and natural language support for creating simulated error conditions to force test execution of rarely used error handling code. An essential aspect of production code is to design in the handling of errors and unexpected conditions. This is true across the abstraction hierarchy; who throws exceptions and who catches them? In C code, how do you encode error returns? Who has the responsibility of printing error messages or notifying the user of a detected error? It would be great if these aspects of a system could be exercised as part of automated software testing, and I believe this would be facilitated by language features that could interact with test case datasets to simulate exceptions.

kscaldef• 17 years ago

This is more a comment on his motivation than the body of the article, but it seems to me that if running your tests requires anything more than typing "make/rake/ant/whatever test" than you're Doing It Wrong. And once your tests are that easy to run, they're also easy to integrate.

txxxxd2• 17 years ago

If Java was designed with testing in mind, there would be no such thing as dependency injection.

WalterBright• 17 years ago

The unit test facility built in to the D programming language has turned out in practice to be a huge win. Sure, it's on the basic side, but the advantages are there's a standard way to do it that is little more than just writing out your tests right next to the function needing testing. This convenience factor tends to make a function look incomplete without the unit test.

10ren• 17 years ago

Similar to the javadoc tool, which has some native support.

wsprague• 17 years ago

In python, it seems like it would be trivial to add a __test__() method to a class that was run, well, whenever.

Should programming languages support unit testing natively?

Related Stories