What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 129 Stack Exchange communities.

Where appropriate, I've started trying to give answers to Java questions using JUnit's Assert rather than System.out.println - such as this one.

To me it seems a bit better for providing more robust answers, and introducing perhaps more professional ways of evaluating variables rather than System.out.

I was just interested to see what people thought about this. Is providing JUnit just being a bit OTT (perhaps saying "I'm better than you" - which I'm not trying to do), and perhaps just clouding the issue, or is it promoting values such as test driven development?

share|improve this question
    
you should ask that question on stackoverflow.com You are currently on Meta.stackoverflow.com. This is not a place to ask programming questions. –  jjnguy Aug 24 '10 at 12:20
3  
@jjnguy - I'm not asking a programming question - I'm asking about the approach to answering questions. –  Noel M Aug 24 '10 at 12:22
    
oops, my bad... –  jjnguy Aug 24 '10 at 12:37

3 Answers 3

up vote 5 down vote accepted

I think this is a great way to provide "executable answers", that can be easily verified. In fact, all the code samples in the Groovy in Action book use this approach.

However, I think using the Java assert keyword is even better than using JUnit's assert. Functionally, the two are almost identical, but you remove a dependency on a framework by using the Java assert instead.

share|improve this answer
    
I like this answer, and have voted it up. However - Java's assert keyword only allows boolean values. JUnit's Assert is a little more descriptive in my opinion, such as assertNotNull or assertEqual. I know that you can make these into boolean statements, but it just seems a little clearer, especially someone who is new to the language - this describes exactly what is going on IMO. –  Noel M Aug 24 '10 at 13:08

It depends on the question, but mostly I would prefer System.out.println to show results and JUnit only if the question involves testing or is about using JUnit itself.

In this question, in particular, I think it's not very helpful - probably the OP does not know what assertEquals is for and it is just introducing another difficulty. It's not directly saying the result of that command is this result. Despite the need to include another library/API.

Sample code should be complete but simple IMO.

share|improve this answer

I think here we have three different concepts we need to discern between: unit tests, System.out.println() and the assert keyword. Unit testing is a systematic way to tell whether an application behaves as expected especially when some modifications of the source code are made. Personally, I'm in favor of the following software design strategy:

  1. Create Interfaces and implementing classes with out body (throwing UnsupportedOperationException)
  2. Create unit tests
  3. Implement the interfaces
  4. Run the JUnit tests

And run the unit tests every now and then to check if everything is as expected. Unit tests should be exhaustive and leave little space for bugs. I point I would like to clarify is that using JUnit does not add an extra dependency in the distribution of your application but exists only locally. Such dependencies are known as "test libraries". Including such libraries (e.g. JUnit or DbUnit) in your classpath is really not recommendable either if you work on a library (so you oblige your clients to have this dependency in their main classpath) or on a standalone executable application such as a GUI (because your executable jar will be larger in size). For example, among people working with maven it is well known that JUnit should be declared as a test dependency:

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>${junit.version}</version>
  <scope>test</scope>
</dependency>

The keyword assert now, though can be used for testing, its scope is different; assert is a handy way to throw Exceptions and in particular RuntimeExceptions or AssertionErrors. Though both declare that something very unexpected has taken place, runtime exceptions are not to be used for testing. More, assertions lie inside the source code while unit tests examine the code's behavior on runtime from the client's point of view proving better insight on what might happen when the software is released. While it's good to "assert" some conditions in the source code, overdoing it leads to chaos (a code foul of assertions, admittedly does not look very good).

Finally, System.out.println() is used by many along with unit tests to output information to the developer and, alas, this is a very common practice among developers probably because it's very easy to do so. In my humble opinion, this is a bad use of the System's output (whether we are talking about Java or any other programming language). So even in the case we need to do something quick and dirty is better to use the System.err for debugging or much better use a logger (e.g. SLF4J). My main point though here is that it's very impotent that the developer will go through every singly output of the unit tests to check if it looks as expected (Imaging doing so with tens of unit tests).

So unit test, assertions and System.out/System.err have all their own purpose. Nothing obliges of course the programmer to follow some specific "musts" or go always by the manual (and I don't think anyone really does) but it's good to find those practices that will pay back in the long term and offer you a well-organized and bug-free (as much as possible) source code. And as far as I am concerned, unit tests definitely help towards that direction despite that it's sometimes boring to write an exhaustive test.

share|improve this answer
2  
...but: does this answer the question? –  Arjan Feb 11 '11 at 14:22
    
From my point of view yes, it does (extensively)! –  Pantelis Sopasakis Feb 14 '11 at 16:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .