views:

83

answers:

3

I'm writing an application in WinForms c# that is over 90k lines big. I am not very experienced coder and after some lines of code (depending if it's something new or something I've done before a lot of times) i start my project with F5 in Visual Studio to verify that the things I've done work as i wanted it to.

For example:

if data from SQL gets populated in ListView correctly
if sorting ListView works as expected (newly integrated feature)
If docx generating works and the docx is created with proper formatting
If counting is done right

Is this the proper way of doing it? Or are there better ways? For now starting up my app is like 5-10 seconds so it's not a big deal, but maybe there's a better way then doing it the way I do it.

I am coding this app alone on one computer.

+6  A: 

Test Driven Development!

Applying unit tests with Visual Studion: A Unit Testing Walkthrough with Visual Studio Team Test

MSDN has a lot more about Development and Testing:

  • A Unit Testing Walkthrough with Visual Studio Team Test
  • Guidelines for Test-Driven Development
  • Introducing Microsoft Visual Studio 2005 Team System Web Testing
  • Microsoft Visual Studio Team Edition for Software Testers
  • Monitoring and Analyzing a Load Test Result
  • Unit Testing and Generating Source Code for Unit Test Frameworks Using Visual Studio 2005 Team System
  • Web Test Authoring and Debugging Techniques

All found here

Filip Ekberg
Sounds like TDD is what i should be doing but isn't it overkill for my project? I mean i wanted to shorten amount of work i needed to get things running (like not having to start whole app to test if ListView columns populate properly). And this seems like i have to write test code for code i already wrote ;/
MadBoy
TDD is never overkill, you end up writing small tests in main anyways or create new projects to try your dlls. It's better to get into TDD right away. And it's good for practice ;)
Filip Ekberg
Yes, it will take longer if you only measure the time you need to code a new feature or change an existing feature. But if you also take into account the time needed to test and retest **everything** you'll be soon faster. Especially you'll find not wanted breaking changes within minutes.
Oliver
In my experience, when you have a test in place, you can write the remaining code in less time. This is because you've already though your code through when you though out the unit test, and because you're not wasting time on checking things that are not strictly related to your change. Also, unit tests, if written correctly can be a good addition to documentation.
Koert
While TDD is certainly very useful in many cases, it is crazy to suggest it is never overkill. I would strongly advise MadBoy to investigate TDD, and weigh up the benefits versus the costs. Hopefully it is the right approach and saves him time, but if he is 98% complete on his project and will never have to do any maintenance on it, he could never justify the cost of a major refactoring now.Also, I wouldn't expect many one man code projects have any documentation. Who would read it?
Modan
I have to agree with Modan. For me it's gonna be costing too much to introduce TDD now. +1 for the whole TDD explanation, but the accepted answer goes for Modan.
MadBoy
There are different approaches to implement TDD, using Unit-tests is just one of them. There are other ways to organize your test/procedures so that you will both increase productivity and quality.
Filip Ekberg
How can he perform TDD on an already completed or semi-complete project?
Chris S
You don't need to set up a unit-suite for the whole project. You can always create tests and apply some methods on the newly added features.
Filip Ekberg
+1  A: 

Given the size of the codebase it sounds like don't have the ability to completely restart from scratch to restructure the code.

If you were at the start then I would advise you to use Test Driven Development (TDD), and to make sure that you keep the user interface code as separate as possible from the rest of your code, as it is notoriously difficult to test in an automated fashion. I woudl still advise you do some reading about TDD, and also about User Interface Design Patterns

It sounds like what you want however is a way to go forwards with an existing body of code though, which I am going to assume is not structured in a way that is amenable to Automated Testing, as this seems unlikely from what you have said.

In this scenario, you are probably doing the right thing. It is certainly important to keep the length of time between you adding a feature and testing a feature short, as keeping this feedback loop short will make it easier to check that your code does what you expect it to do since you wont have forgotten what you were trying to achieve when you test it.

If you find that you are wasting a lot of time compiling and loading your app try and bunch related changes together particularly when doing simple changes. This should help you to get the balance correct.

Although I am assuming you cannot make wholesale changes to existing code, something you may be able to do is to write new code in a more testable way, and write unit tests for those, but you will have to weigh up the cost of having code which ends up with a number of different coding styles against having one coherent style.

Modan
Although other answer suggested was voted up higher then yours I think you gave me the exact answer to question i needed. I will certainly look into TDD but benefit in having it now when i am very short on time would be smaller then expected and it would even make it harder for me to finish it on time.
MadBoy
A: 

If data from SQL gets populated in ListView correctly /

If sorting ListView works as expected (newly integrated feature)

I've never had experience with winforms test frameworks (only web ones like Watin), however I know there are a number of windows forms testing frameworks, such as NUnitForms. These automate testing your winforms application to test if certain text appears on the screen, if a button click takes you where you expect and so on.

These UI test frameworks are never perfect at eliminating every corner case, but are always a lot more useful than not having them at all.

If docx generating works and the docx is created with proper formatting

You could check the file exists in a unit test. For proper formatting - the best way of achieving this would probably be adhoc tests - that is someone viewing the output with a set of tests written on script (usually in Excel).

If counting is done right

This is prime fodder for unit tests, about 6 .NET frameworks exist for this. One is already built into Visual Studio 2005+.

Chris S
As for someone viewing the output that person would be me. Unfortunately i am one man army on this project so everything i do will have to be tested/viewed by me and only me. Later on when i think application made some progress I pass it to users directly and they report with their findings.
MadBoy
@MadBoy The time it will take to write meaningful tests to verify the layout of your Word document, you could have manually tested it yourself 100 times (assuming you aren't generating 100s of documents and just a few)
Chris S
Ye, that's why i am gonna hold on to what I do now :)
MadBoy