Automated Unit Tests in my life – Part 2

Part 2. First experience

A day later I began to like it… And you know why?
Here are the first things I liked about automated unit tests and the 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 !!!
Why else does it save time?
a) I do not have to write “*.exe” tester. (or some Gui tester)
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 colour). Assert is done automatically in runtime and you do not have to look at each test result visually.
Think about 10 tests that run in a second and you can say at once if they passed or failed.
How long it takes to run each of them and look at the result vusually (sometimes using debugger) ???
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 (objects creation or termination, initialization or etc…) to number of tests, because Test Initialize and Test Tear Down is called automatically with each test for test project (file).
Automated – helped me to find bugs in my code and produce better quality code in the short time
a) I wrote function, test passes, i wrote more code to function, wrote one more test. The new test passes, but it appeared that I broke the last test with new logic. I knew it in a minute – when I ran 2 tests automatically – figured out that have “broken” one of tests by adding code.
First test was RED !!!

So I had to go back and fix code. I realized now that I can come quicker to a higher quality code.

2) Visual view at all tests helps to understand if there are more situations and scenarios to be tested
On the second day when beginning to work with my code, I looked at the tests and could “see the implemented logic”. Each test name was a question. When you see the tests – you can easily understand if you missed some tests:
Later I figured out that my work became to look like a game. I the next part I will
write about this cool experience…