unit test

[andrewpaterson]

Hi all,
I'm new here, and a real beginner.
I need to write some unit tests for a windows
form I'm working on, I really don't know where to start
other than adding the unit test to my project.
Any help would be much appreciated .
I'm also having trouble creating a function
that does the job of many lines of code, boolean
I'm thinking, not su really of the syntax, will provide some code later to clarify ...but an example of unit testing before actual code is written (as it should be done as I understand tdd) and how to test existing code
would be much appreciated, it seems all the resources out there are in c# which I'm not familiar.
Thank you all
Andrew

[dolot]

I haven't done tdd, but recently I got assigned to write some unit tests for our application. I found that the easiest functions to unit test were single operation functions - that is, those that only did one thing. Functions that performed multiple operations or that called other functions were much more difficult to setup, and in the latter case, it was really hard to tell, if an error was thrown, where exactly it was - in the function or in one of the called functions.

So all that to say... if you have existing functions that are simple, go after those first. If they aren't, then take a look at refactoring them so you can break them down into single operation functions. This is really good programming practice anyway. Your functions will be more reusable if they are isolated to a single function, and you can unit test your code easier. It also seems to me that my application is sturdier if I break things out into individual functions as much as possible - and then call those functions from different places. That way, if there's a problem, I can fix it in one place and have it be fixed everywhere.

And like all the examples you found, my code was written in C# also, so I can't give you a VB example.

[andrewpaterson]

Thanks very much for the response!

[Evil_Giraffe]

It would help to give a bit more of an idea what your form is going to do. First thing to note is that you will get pushed by your test to write your logic separated from the UI, so it will help to be familiar with patterns for decoupling UIs. Other than that, it's just a case of remembering to focus on behaviours of your classes.

[andrewpaterson]

Hi, had to create a basic form that simulated a football
game with players, stopwatch, to keep track of scores from players and countries chosen to play against each other. A lot of buttons, labels, combobox etc
I wrote code into event handlers and some functions and subroutines that were called from event handlers. It's my understandING now that the unit tests must be run separately and not return a value ? Also that with tdd in fact methods tested before any code is actually written in the code? Sorry, I am a beginner and struggling to get my head around this. Tests trying to get a return/expected value returned null and that the function code was not accessible at all levels ? Confused?
An example of how to create and run unit tests would be much appreciate

[FunkyDexter]

There are a variety of tools you can use to do unit testing so I'm assuming you just want to use the one that comes with Visual Studio. It's not the best out there but it's almost certainly good enough for you to cut your teeth on.

You have presumably already created a solution and project for your game.
Add a new Project and select the project type as "Test Project".
Add a reference from the test project to the main project.
Your test project should have had a boiler plate class called UnitTest1 automatically created and when you look in that you'll see a boiler plate method called TestMethod1(). In order to test a method in your main project you simply call it from a test method and check that it had the expected result using assert statements.

At it's most basic that's it.

You should note that you can't really use unit tests to test a UI. They are intended to test underlying functionality. So you won't write a test that enters two scores into text boxes, pushes a button and checks whether the winning team is displayed on a label, but you might test that a function that receives two scores as parameters returns the correct winning team as a result.

[NeedSomeAnswers]

Also that with tdd in fact methods tested before any code is actually written in the code? Sorry, I am a beginner and struggling to get my head around this.

Forget TDD for now, to do TDD you need to be starting a fresh project and actually have your development driven by your tests, so very simply you write the test first and then write the method to make your test pass.

TDD is a different way of thinking and developing and you probably want to first understand Unit testing !!

[andrewpaterson]

There are a variety of tools you can use to do unit testing so I'm assuming you just want to use the one that comes with Visual Studio. It's not the best out there but it's almost certainly good enough for you to cut your teeth on.

You have presumably already created a solution and project for your game.
Add a new Project and select the project type as "Test Project".
Add a reference from the test project to the main project.
Your test project should have had a boiler plate class called UnitTest1 automatically created and when you look in that you'll see a boiler plate method called TestMethod1(). In order to test a

At it's most basic that's it.

You should note that you can't really use unit tests to test a UI. They are intended to test underlying functionality. So you won't write a test that enters two scores into text boxes, pushes a button and checks whether the winning team is displayed on a label, but you might test that a function that receives two scores as parameters returns the correct winning team as a result.

Thanks for the replies, how would I go about this?
thanks

[FunkyDexter]

how would I go about this?

Follow the steps as I described. What bit are you stuck on?

[SJWhiteley]

Think of a Unit Test as a tool used by Mr. Evil. It's more important to do this if you are testing the code you, yourself, have developed.

As Mr. Evil, you job is to really T-off the developer, and demonstrate how useless he is by breaking his code. Effectively, your tests will be checking for wrong behavior, not necessarily correct behavior (of course, the latter is what you want).

For example, you have a class with a method which takes a string and returns a number. You, as the developer of that class expect a string that represents a number. Mr. Evil, on the other hand, will perform the the basic Mr. Evil Minion tests, like passing in simple numbers represented by a string. Okay, so you pass the basic test. Then you send in Mr. Evil Mini-Me; strings which may not really be numbers, but look like numbers (e.g. "6 78"), then really ramp up to "465764573465243423536445674563465342353534635747346363637637634534235634635"... Then Mr. Evil steps in and throws in "Brian", or "Six" or Nothing.

So, you test for expected behavior and attempt to return unexpected behavior. This leads to another point: before you even create your test, or even your object under test, you have to define what you expect as inputs, and the behavior to those inputs, and when you receive unexpected - or not defined - inputs, the behavior under those conditions.

Consider the above example which takes a string. What is the expected input? Perhaps the input should be a number between 1 and 6 represented as a string, but it is not clearly documented as such (as part of a specification, for example.) The unit test should be based on what the object is expected to do as part of a documented process, and not what the code is written to do. This is why it's more difficult to unit test your own coding, as you already have a preconceived notion of 'input' based on the code.

Unit tests are necessary because coders are notoriously bad at writing code to a specification (it doesn't help that documenters who create specifications are notoriously bad at writing specifications). This is also why testing departments need people who would be right at home in the IRS.

EDIT: Personally, when I unit test my objects and projects, I'll let the code simmer for a few days, work on other projects and tasks, then come back as a 'unit tester': I'm going to use and abuse the objects I've created, paying particular attention to how I've documented and commented the objects, and avoid looking inside the objects at the code. So the first hurdle is to look at the object and see that it tells me the basics of how to use it properly; Test Zero.

[Evil_Giraffe]

EDIT: Personally, when I unit test my objects and projects, I'll let the code simmer for a few days, work on other projects and tasks, then come back as a 'unit tester': I'm going to use and abuse the objects I've created, paying particular attention to how I've documented and commented the objects, and avoid looking inside the objects at the code. So the first hurdle is to look at the object and see that it tells me the basics of how to use it properly; Test Zero.

Assuming the point of "letting it simmer for a few days" is so you can forget about how it works internally and approach it fresh for the tests, why not write the tests before those internals have even been thought about? a.k.a. TDD

And I don't think you have to learn about unit testing before you start TDD. Most of what you need to learn when you start doing tests second is how to write tests to exercise untestable code. With TDD you can't write untestable code, by definition.

[SJWhiteley]

Assuming the point of "letting it simmer for a few days" is so you can forget about how it works internally and approach it fresh for the tests, why not write the tests before those internals have even been thought about? a.k.a. TDD

...

While that's true, there's an element of practicality involved. I know we don't admit it, but we often pay lip service to a 'design document' and start face rolling the keyboard to produce code. At least if we know there's a big gorilla with a baseball bat when we churn something out, the hope is that we write defensively in the first place; permissive in restrictive out, or however that phrase goes.

This forces us to test as we develop, anyway. Once we know whatever we expose is going to be beaten like a drunk beats a whippet, we will start to write more defensively at a lower level, which necessitates rapid (internal) test cycles.

Further, there are basic designs which solve a lot of the failures of code: validation. Correct validation will prevent most code failures, and force us to think about what-if (test) scenarios.

As another personal note, as part of the testing cycle, I always leave my code in an excecutable state. Every DLL/Library has an executable attached to it which, effectively, is a test project (it's just done manually).