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.

Software Experience: Automated Unit Tests in my life

Introduction

This is an article of a software developer, who decided to share some knowledge and experience in automated unit tests. I think this one can help in everyday work of people like us.
This is not a pure technical article. It is a real story and comes to help producing better quality code. I will try to give some nice tips and show black and white sides of my automated unit tests experience.
About the name of an article ... You might ask: Hey, man – isn’t it too much? You could name it “Unit Tests in my code, work, or etc – but “in my life”? You will find the answer on that question by reading this material, which consists of several parts. And here they are:
· How did it begin – how, when and why did I begin using automated unit tests
· My first experience – Good, bad, why do I need it
· The New style of work. How could Programming be like playing a game.
· Programming without automated unit tests and Test Driven Development - differences
· Programming without automated unit tests and Test Driven Development - differences
· Self confidence in your work
· Automated unit test weakness and how to prevent them
· How can we mock without affecting the code