Software: Automated Unit Tests in my life

Part 1. How did it begin?
Before writing about automated unit tests technical details, I will write you about my experience with the automated unit tests… A little bit about my programmer history:
After graduating University in 1997 (Applied Mathematics), life took me to work as algorithms and software developer in some complicated big project with lots of mathematical calculations and logical stuff, where I earned lots of programmer skills. The project was one those, where all the developers had to make lots of tests (the situation where quality was more important than time). All the team tested all code by writing unit tests and integration tests. This is why the quality of my code was good. At the time I did not know anything about automated unit tests. All the tests were written manually…

So when the automatic unit tests came into my life? All began with my work in some software medical company. After about a year of my work in the company my boss suggested me to “try” write unit tests automatically, using “Nunit” and more then that – write tests before code (test driven development).
I was shocked and disappointed… First of my thoughts were:
”Why me? Is my code not good enough? I have a good testing experience with my working and testing style. Why should I change the way of working? More than that - why should I write the tests before code? And changes now - when I have so much work?” It felt like some entering to my privacy – way of programming, way of life, thinks I was used to… But as you can understand- I agreed, because am writing this one. After few hours of practicing I still did not understand why automated unit test and test driven it so good? In the next part you will see why first experience began to change my opinion…

Part 2. First experienceA day later I began to like it… And you know why?
Here are the first things I liked about automated unit tests and test driven:
First of all – I realized that writing tests and code using automated unit tests did not take more time then my “regular” way of working at that time. Now before writing a new function (method) in class I write test that calls that function. I have to think about how client will call my function, about possible arguments and possible returned values – this saves time.
1) Why else does it save time?
a) I do not have to write “*.exe” tester after my function was finished.
b) I do not have to look at test results visually, I can see at once if test is passed (green colors)
Automated means – you write expectations and results and expected results are compared automatically. This is a part of an assertion code
Assert.AreEqual(actual, expected);
If expected is equal to actual, the test is passed (green), if not – test is failed (red light). Assert is done automatically in runtime and you do not have to look at the test result visually.
c) It is easier and quicker to write a test that uses files (text or XML)
d) I did not have to write same initialization or tear down code to number of tests, because Test Initialize and Test Tear Down is called automatically with each test for test project (file).
2) Automated – helped me to find bugs in my code and produce better quality code in the short time
a) Once after testing my function and adding more code – some private function that is used by number of publics, I ran 2 tests automatically and figured out that have “broken” one of tests by adding code.
So I had to go back and fix code. I realized now that I can come quicker to a higher quality code.