Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am, and like being, a VB.net coder. I have a couple of largish programs in c# that I must maintain and I don't really like writing C# code while developing. It isn't horrible but I much prefer the VB.net environment for development.

However recently I have started writing all my tests in C#. I started doing this so I could use all the great tools, such as the mock libraries, available in C#.

But even after I found Teleriks extremely capable justmock free edition for VB.net I have found I still write almost all my tests in C# (now using the C# version of JustMock BTW). Even when I don't need these testing tools I find that I just like C# better for writing tests.

I think I like VB.net for general coding while solving problems as I write because: 1. Like the sugary sweetness of things like XML Literals. Plus LINQ just seem easier and more expressive in VB. 2. Don't need worry about the syntax nearly as much (casing, line terminators etc.) I can focus on my ideas. (The extra verbosity is handled by #3 below and coderush and other IDE tools) 3. Think the tight integration with IDE of Visual Studio and VB.net (background compiling for example) is just the bees knees. (Though C# is getting much better.)

But for tests I am not thinking about the big picture or really solving problems. Each test method is independent and the succinctness of C# just reinforces and aids this fact.

I initially found this surprising because I always thought a scripting type language would be better for writing tests. But after actually writing many thousands of them I don't see any benefits in using a scripting language. In fact I find Option Strict and Explicit being true (which turns of the scripty nature of vb) even more helpful in the test projects.

But maybe I am wrong and there are languages even more suited to writing tests? Would something like IronPython be good for writing test? Maybe BOO with its macros? I wouldn't think so but might a functional language bring anything to the table?

More simply, are there language features that aid in writing good tests? And if so what language has the greatest numbers of these desirable features?

share|improve this question
    
The last sentence, closely related to the title, is the question. The body is the context or why I asked the question in the first place. I added this context so that people that may not be heavily into writing tests would, hopefully, have a better understanding of why the question is relevant. I often read questions on other stackexhange site and wish for a bit more context. –  ElGringoGrande Nov 11 '11 at 4:24
add comment

2 Answers

I would say that it's more important to write your programs in a testable way than it is to seek specific language features that aid in that testing. You can write tests in python or clojure just as easily as you can in c# or Java, if you write your programs in a way that facilitates that testing.

As a committed c# developer, I can tell you that there are definite advantages to having a structured, strongly-typed way to write programs and unit tests. But there is something to be said for working in a language that has more "immediacy" like python. By utilizing a REPL, you can more quickly distill your ideas into testable pieces of code, and in the long run, you might need fewer unit tests, since you are constantly testing your code as you write it.

share|improve this answer
    
I agree that if the code you write is not inherently testable the language of the tests doesn't help. (Tools can help and if tools are for a language then it can appear like the language makes a difference. However it is not actually the language but the tool. I tried to point this out). But if it is inherently testable code then I have found that the language, at least for me, does make a difference. –  ElGringoGrande Nov 11 '11 at 4:29
    
In what ways?.. –  Robert Harvey Nov 11 '11 at 7:14
    
I find it helps if you can split your program into independent components and a layer of glue. Then test the heck out of the components and make the glue simple enough that it has Obviously No Failures (as opposed to No Obvious Failures, the normal state of most stuff that seems to get shipped). Not that this is a magic bullet — there are whole classes of bugs this won't find — but it limits the complexity of the testing. (I like to use a scripting language for the glue layer, but YMMV.) –  Donal Fellows Nov 11 '11 at 10:21
add comment

I think a lot depends on if you're talking about testing that's integrated with your own code or testing as a separate activity. It depends on what you're doing, how your team is made up and so on - but often a combination of the two is the most powerful.

For integrated testing (unit testing, integration testing, executable specifications written by developers, etc.) then you simply have to make sure that you're coding in a way that makes it easy to test - IMHO what this means can vary from language to language although there are some general principles (loose coupling, minimise dependencies external dependencies to things like file systems or databases). In any case the problem you're trying to solve should determine which one to choose not the testing requirements.

For external testing (e.g. executable specifications written by testers or analysts) you can use the same language that you are using to write the code, but often you'll want something a bit more interactive. Avoiding a compilation step and having a REPL can be a big win here (e.g. python).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.