locked
Unit testing for beginners? RRS feed

  • Question

  • I haven't found any beginner articles on how to use unit testing in VB. I'm not even sure exactly what it is (well, I understand the general idea). I'd love for some info or pointers for how to use this technology to help me write more robust code. Can anyone out there help me? Keep in mind that I'm not a enterprise developer working on an n-tier scalable system, in a large scale team environment, blah, blah. Just an intermediate level coder that writes his own small scale stuff.

    Thanks!
    Wednesday, March 1, 2006 5:28 AM

All replies

  • Why do you think you need to do 'unit testing'?
    Wednesday, March 1, 2006 1:04 PM
  • It's not that I need to. But my code gets bugs creeping in as it gets more complex and gets more difficult to debug as it grows, and from what I understand, that's exactly what unit testing is meant to prevent.
    Wednesday, March 1, 2006 4:03 PM
  •  aburstein wrote:
    ... from what I understand, that's exactly what unit testing is meant to prevent.

    . That's pretty funny, actually.

    What Jack said are great resources. However, things can get mighty expensive using Team Suite to test a single or (several) programs.

    Don't kid yourself, though. I have witnessed first hand a team of people using such tools (a few years ago), and still produced a buggy program (it crashed on the users desktop often). Complaints were ignored, since they had tested the program in all ways possible, in a rigorous manner: there weren't any bugs (mind you, I'm pretty cynical about such things - don't write buggy code in the first place: write every routine as if it's going to be used by a moron who wants to see your program die in flames).

    Oh, and Jack: a Bugs Layer? Is that like sweeping them under the rug?

     

    Thursday, March 2, 2006 12:18 PM
  • The links were helpful. Thanks. I actually only had a chance to go through the first one, but it was worthwhile, and gave a good intro.
    Friday, March 3, 2006 8:04 AM
  • I read that is Bug Slayer

    In the VB.NET Webcast series here:

    http://www.microsoft.com/events/series/modernsoftdev.mspx

    On the episode about Best Practices I think he mentions a number of tools about unit testing - among them is nUnit, a popular tool for .NET Unit Testing prior to Team System. It still has a large niche for those who don't have thousands of dollars.

    http://www.nunit.org/

    As for righting your code right the first time I think that's like saying "raise your children properly". Computer programmers despite their god-like powers of manipulation are human and make little mistakes. More importantly unit testing automates keeping code within the functional specification after minor modifications. The problem you mentioned about developers using Unit Testing in lieu of customer feedback is a sad mistake but not really the fault or natural progression of those who subscribe to unit testing.

    It's good that you're trying to make better more robust code. When you get to a certain point it become more than a single developer should reasonably be expected to perform however.

    Friday, March 3, 2006 6:22 PM
  • Anthony, perhaps an attempt at irony was lost in translation. The internet will do that .

    I think you infer that I don't subscribe to the 'unit testing principle': you are right, I don't (just like I see six-sigma as an emperor with no clothes). My belief is that unit testing simply ensures that poor coders don't bring down the whole project. Perhaps I am saying "raise your children properly": quite true, because the village could care less about them, and just wants to ensure they don't grow to harm the other villagers: any rule/test made by the village is not for the childs benefit.

    Hmmm, this is getting a bit far fom the beaten path. But I concur that it is certainly good to make better and more robust code. Unit testing is a tool, and only a tool, to do so. And I also agree; my example demonstrated the shortsightedness of the individuals involved [in unit testing] and not unit testing itself. But it's a trap that those who don't know better fall into - and there seems to be a lot of them around, unfortunately.

    There are two rules in life. Rule number 1: follow the rules and everything will be great. Rule number 2: you need to break rule number 1. Perhaps my cynicism is starting to show . Now back to our regular programming (pun intended?).

    Sunday, March 5, 2006 12:16 AM