I'll assume that you mean a first programming course that uses a language (Java...) that has well integrated testing tools.
If you just use unit testing as an add-on then I'd guess the proper answer is no. There are other things the student could be doing.
However, if you are willing and able to modify your teaching a bit then unit testing can be a big win. I've used it in teaching introductory programming to adults for years (since back when Extreme Programming was young).
I do two things. First, I give out assignments differently at the beginning. Rather than giving students a narrative to describe a programming exercise or project, in which they must first decompose the description into tasks, I give them the task list itself. In Agile Programming language, I give them a small product backlog or story-card deck. The tasks are numbered in a logical (do this first) order so that when the backlog is completed the project is done.
Therefore I'm using a bit more than just unit testing. Other "personal" agile programming practices are employed, including pair programming. I also act at the student's Customer, answering questions as needed.
The second thing I do: On the first day of class I do a demo project in public. I start with a small number of "stories"; tasks that decompose a simple project. I pick out a student (volunteer or other) and we pair program on a laptop connected to a projector so all can watch. I start out as the "driver" with control of the keyboard and my student is the "navigator". He or she may know nothing of programming, or very little. We look at the first story, discuss it a bit to get a "picture"/analogy/metaphor. I then fire up Eclipse, start a new project add JUnit to the project and write a test for just that one card. It fails of course. So then we (my nav and I) write app code to make that test pass. Repeat. At some point we switch roles and the student becomes driver and I act as a very helpful navigator. If the class isn't too large you can also open "navigation" (comments, questions,...) to the class as a whole, to get them used to the process of aiding the driver.
Along the way I discuss what we are doing at each step (go "meta"). This can take up much of the period, but if you have enough time you can distribute the code you've done to the class. They can pair and work on the next story as you wander about giving help.
So, they see unit testing and pair programming and build on the test-first philosophy in an integrated way.
Another thing, that works well with this is that, when you assign them a project, you can give out a unit test suite along with the product backlog. In other words, you write the unit tests and they make them pass. The down side of this, however, is that the tests contain identifiers from the app (class and method names for example). In the big picture, the test suite is your low-level design space where you decide on such things. If you write a test for the "increment" method, you will normally do it before you even have a stub for the method. In writing the tests you discover the name as well as the args it should have and its return type. If you give the tests initially you have already done this step and so need to teach it a bit later. Maybe by the 3rd exercise.