Starting to debug c#, how to test code to ensure he acts like he should?

Question

I've made a relatively simple code (uses a few forms, has all-forms wide variables and database, knows when it's running for the first time, which has its own implications, etc.. )

As some of you know i'm really beginning, and the code works fine so far when its use is expected, for example, a configuration file is not deleted, or has its name changed.

Even so i took some precautions, but i'm afraid it might have some unexpected behavior, what should a beginner read in that matter?

Is there anyway to test it deeply without having to try every possible combination of uses?

Thank you

edit: for those who haven't read already, i'm getting s*** scared of it, because it already happened, i've patched nearly half the code to deal with unexpected behavior :)

Answer 1

This question is pretty broad, but I'll take a stab at it:

1. The first line of defense in corner cases is to write unit tests. These will ensure that all the scenarios you can think of always work (because you can run the tests all the time, after every build ideally). Of course, such tests are only as useful as you make them. Also, you need a decoupled view-logic system for unit tests, so that you can mock out anything the logic tries to do with the view.

2. A second line of defense is automated UI tests these are useful for testing user input and making sure the system doesn't crash, the correct output occurs, etc.

3. The final line of defense is functional, integration, and acceptance testing. These tests are run manually, and yes, you pretty much have to try "every possible combination of uses".

In the end, for an app to be tested, it has to work in every use case you can come up with. There isn't any free lunch, and there certainly isn't any magic testing framework that will come up with all the potential problems for you.

A few unit testing frameworks: NUnit, MSTest

Microsoft Automated UI testing: MSDN

Update

If you are in a professional programming/engineering situation, you generally have a QA department whose entire job is to try and break your software. If you aren't, there probably aren't a lot of other coders around to exchange code with :). That being said, having people just try and use your program can be a great way to test it:

1. You can get good feedback on UX problems
2. They might find some corner cases you missed
3. They could spread word-of-mouth about your software if they liked it!

Without others though, it is still possible to write good tests. A few guidelines:

1. Are you dependent on an external resource, like a file or database? What happens if it is unavailable? Corrupt? Junk data?
2. Are you dependent on the user performing actions in a specific order? Do it in every wrong order you can think of.
3. Do you have input that goes beyond strings? Put bad data in (characters in a number, for example). Test against things like SQL injection as well.

In general, you know your code best, so you should be able to identify what problems the code could have. In other words, if you can think of places where "this would break if < insert impossible scenario > happens" it WILL happen; make sure you handle it, write a unit test for it, functionally test it, etc.

Having explicit use cases that say what the program should and shouldn't do can also guide you along this path. In a professional environment, these almost always come from your employer. As a hobbyist, you just have to come up with everything you can think of. Make sure each use case has test cases for correct behavior, and anything that could go wrong along the way.

Hopefully that helps!