Should we be suggesting Unit Testing?

[aussiemcgr]

This is mainly for the other helpers on the forum: when it comes to helping someone with their issues, should we be advocating unit testing more (or at all)? It seems to me that a lot of basic issues we see from new java programmers could be solved/debugged if basic unit testing was done by the OP. It is something extremely useful they could probably benefit from learning. It also encourages programmers to split up longer methods into smaller, more manageable ones (largely so code is easier to unit test).
Keeping in mind that many of those who ask questions here are new to java (and usually programming in general), would suggesting unit testing be too "over-their-head", or something we should consider starting to do?

[newbie]

I understand the point you're getting at, but the work involved in this, in correlation to the simple problems most users face is way too much work. At the bare-bones level, it usually involves downloading jars, adding jars to the build path (IDE dependent), importing libraries, creating multiple classes, using annotations and reading the relevant APIs. Agreed, after a certain threshold this work is trivial and hardly takes up any time, but we're typically dealing with new learners, who if taught responsibly, are starting off with the command line.

Something you've noted however, is the ability unit testing has to highlight problematic areas and quickly resolve issues. With this in mind, I believe the best course of action would be to get an article or a blog up which acts as an introduction to unit testing and when a question of a sufficient skill level arisies which could be quickly resolved with this, you point them in the direction of the blog/article.

Obviously everything i've referred to is with respect to unit-testing frameworks. Although users can easily make their own test harnesses without any library, my personal belief is that if you're ready to get into unit testing, you should be ready to use one of the defacto frameworks. However, some people might not agree with me on that.

[aussiemcgr]

In my experience, there are not many blogs out there that describe unit testing in such a way where it isn't daunting to first timers. I agree that the dependency issue is significant if you are not using an IDE with junit already included.
But, perhaps we could suggest an alternative for those who just want to dip their toes in it. Something as simple as asking them to create another class with just a main, which sets up variable to send to the problematic method, calls the method, and then prints out the output could replicate most of the the unit testing behavior, without having to be dependent on the junit framework.
The problem I see with newbies on this forum is they approach the problem from: given my input in the beginning, why is my output in the end wrong?
That is a very unproductive approach to debugging. Ideally, they should be questing the input and output for every single step of their program, not on just the input and output for the entire program.
At the very least, unit testing forces the OP to be very aware of their intended input and output.
Alternatively to even this, we could encourage the use of the assert keyword in buggy code. It would get the user to be aware of their intensions without having to create another class or require on dependencies (the assert keyword is built in, I'm not talking about the JUnit Assert class).

[KevinWorkman]

I see your point, but we already do ask for that: we ask for an SSCCE that demonstrates exactly and only the problem in as few lines as possible. I think asking for formal unit testing is a bit much for a newbie (especially because most of them can barely cobble together an SSCCE). But asking them to break down the problem into smaller pieces and approach each piece one at a time is exactly what we already do.

But if you want to throw together a blog about unit testing and point them to it, go for it!

[aussiemcgr]

I think the problem with the SSCCE for newbies is that they see it as too confusing. Most of them seem to think that their programs cannot be simplified, since they believe the cause of their problem is an entire program thing, instead of what is usually just a single line of code.
What the SSCCE doesn't address, which I feel is the root-cause of so many issues, is a complete disregard for coding standards. I'm not sure who these teachers and professors are who are teaching all of them coding but, with the exception of perhaps GUI creation, you usually should not have a method which is 100+ lines of code (I think at work, our limit is 50 lines), especially not a main which is 100+ lines. That code should be divided logically into different methods.
Too many times do we see someone who has ALL of their code in their main. While I understand where the teachers are coming from, it is a horrible thing to encourage.

I'll consider throwing together a simple blog or tutorial regarding how to "properly" divide large code segments, and then perform unit testing (whether with the junit framework and/or just a class with a main that tests the methods of another class) on code after I get through with the next release of my personal project.

[KevinWorkman]

I can agree with the basics of what you're saying, but you can't really hold newbies to the same standard as a professional developer. You have to pick your battles so as not to overwhelm them. Maybe they don't really know how methods work, so everything is kept in the main method until they learn the basics of variables, if statements, and for loops. Proposing unit testing will go over their heads, I think. But encouraging them to break the problem down (is it your input or output? can you hardcode the input and get it working? what are the values of each variable before, during, and after that loop?) is actually teaching the skills that are required for unit testing. You can't require unit testing before teaching the prerequisites of isolating the problem, which we try to teach by asking for an SSCCE.

But like I said this is really a personal preference. If you want to try to ask for unit testing, go for it.