Test First , Test Last or Test At All?
-
Hi everyone, I'm curious about other peoples views on unit testing. The company I work for is quite small and there are only four full time developers. We all have different views on programming styles ranging from very old school, constantly questioning the need for object orientation, through to very modern, arguing for progress and trying to keep everybody up to date. We adopted unit testing around two years ago and, although the overall development process takes a little longer, I think everyone agrees that it's more than proved its worth. In general we have written our unit tests after we have written our code but, for me, it has never really seemed like the correct or logical way to do it so recently I have been trying test-driven development and I have found it to be quite useful. I guess really I am keen to know what other people think about the whole approach to unit testing.
test the functions or key parts of a function, classes etc test the whole application, try and break it. then leave it for the QA department to break :) p.s i try to test every element of the application which is easier when your building it, than when you have a finished application. oh and exception handling helps :)
-
Hi everyone, I'm curious about other peoples views on unit testing. The company I work for is quite small and there are only four full time developers. We all have different views on programming styles ranging from very old school, constantly questioning the need for object orientation, through to very modern, arguing for progress and trying to keep everybody up to date. We adopted unit testing around two years ago and, although the overall development process takes a little longer, I think everyone agrees that it's more than proved its worth. In general we have written our unit tests after we have written our code but, for me, it has never really seemed like the correct or logical way to do it so recently I have been trying test-driven development and I have found it to be quite useful. I guess really I am keen to know what other people think about the whole approach to unit testing.
Unit testing is something I have been heavily into in the last 12 months or so (I use the Boost Test framework for my C++ code) and I always write a unit test immediately after writing a function/method. Unit tests rock - my code is more reliable, and the tests have picked up some very obscure bugs that might not of manifested themselves 'in the real world' for a long time. The only downside is that I spend a lot more time compiling/linking as I run the tests so often. However, I think the benefits outweigh the time it takes to write and run the tests - I can't imagine working any other way now.
Kicking squealing Gucci little piggy.
The Rob Blog -
Hi everyone, I'm curious about other peoples views on unit testing. The company I work for is quite small and there are only four full time developers. We all have different views on programming styles ranging from very old school, constantly questioning the need for object orientation, through to very modern, arguing for progress and trying to keep everybody up to date. We adopted unit testing around two years ago and, although the overall development process takes a little longer, I think everyone agrees that it's more than proved its worth. In general we have written our unit tests after we have written our code but, for me, it has never really seemed like the correct or logical way to do it so recently I have been trying test-driven development and I have found it to be quite useful. I guess really I am keen to know what other people think about the whole approach to unit testing.
I've yet to be sold on literal test first. I prefer an iterative approach - write some code, write test, write more code - iterate. However, writing all of the code and then retrofitting tests is a very poor strategy. Early unit testing forces you to write code that is testable and cleaner and more maintainable as a result.
Kevin
-
Hi everyone, I'm curious about other peoples views on unit testing. The company I work for is quite small and there are only four full time developers. We all have different views on programming styles ranging from very old school, constantly questioning the need for object orientation, through to very modern, arguing for progress and trying to keep everybody up to date. We adopted unit testing around two years ago and, although the overall development process takes a little longer, I think everyone agrees that it's more than proved its worth. In general we have written our unit tests after we have written our code but, for me, it has never really seemed like the correct or logical way to do it so recently I have been trying test-driven development and I have found it to be quite useful. I guess really I am keen to know what other people think about the whole approach to unit testing.
Take the Microsoft option and get your users to test it after release.
-
Unit testing is something I have been heavily into in the last 12 months or so (I use the Boost Test framework for my C++ code) and I always write a unit test immediately after writing a function/method. Unit tests rock - my code is more reliable, and the tests have picked up some very obscure bugs that might not of manifested themselves 'in the real world' for a long time. The only downside is that I spend a lot more time compiling/linking as I run the tests so often. However, I think the benefits outweigh the time it takes to write and run the tests - I can't imagine working any other way now.
Kicking squealing Gucci little piggy.
The Rob BlogRob Caldecott wrote:
The only downside is that I spend a lot more time compiling/linking as I run the tests so often.
Simply don't use Boost! :)
-
Hi everyone, I'm curious about other peoples views on unit testing. The company I work for is quite small and there are only four full time developers. We all have different views on programming styles ranging from very old school, constantly questioning the need for object orientation, through to very modern, arguing for progress and trying to keep everybody up to date. We adopted unit testing around two years ago and, although the overall development process takes a little longer, I think everyone agrees that it's more than proved its worth. In general we have written our unit tests after we have written our code but, for me, it has never really seemed like the correct or logical way to do it so recently I have been trying test-driven development and I have found it to be quite useful. I guess really I am keen to know what other people think about the whole approach to unit testing.
chambers-chris wrote:
Test First , Test Last or Test At All
Test-icle !? :rolleyes:
[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]
-
Unit testing is something I have been heavily into in the last 12 months or so (I use the Boost Test framework for my C++ code) and I always write a unit test immediately after writing a function/method. Unit tests rock - my code is more reliable, and the tests have picked up some very obscure bugs that might not of manifested themselves 'in the real world' for a long time. The only downside is that I spend a lot more time compiling/linking as I run the tests so often. However, I think the benefits outweigh the time it takes to write and run the tests - I can't imagine working any other way now.
Kicking squealing Gucci little piggy.
The Rob BlogWhat do you do for the functions you can't write tests for (i.e. ones that depend on specific external conditions?). For example, imagine a function that took a URL, fetched the page, and returned the contents of the page. How would you unit test that?
-
Hi everyone, I'm curious about other peoples views on unit testing. The company I work for is quite small and there are only four full time developers. We all have different views on programming styles ranging from very old school, constantly questioning the need for object orientation, through to very modern, arguing for progress and trying to keep everybody up to date. We adopted unit testing around two years ago and, although the overall development process takes a little longer, I think everyone agrees that it's more than proved its worth. In general we have written our unit tests after we have written our code but, for me, it has never really seemed like the correct or logical way to do it so recently I have been trying test-driven development and I have found it to be quite useful. I guess really I am keen to know what other people think about the whole approach to unit testing.
I adopt Unit Testing (whether NUnit or CPPUNIT) into my workload and have found they do increase my overall productivity, long term maintenance and respect for my code. Having developed tests (fixtures or cases) prior to (my preferred method) and afterward and executing the history of my work within a short period of time is satisfying and provides a benchmark I can refer to. I also have a tendency to put issues reported to the bug system into my test sets. Though I am greatly passionate about keeping historical records of my work. Encouraging others to do is more difficult task - therefore being a little more imaginative to integrate testing with the build sequence (I haven't tested VS Orca's facilities yet) is needed. Beth
--- Elle A Du Shell
-
Hi everyone, I'm curious about other peoples views on unit testing. The company I work for is quite small and there are only four full time developers. We all have different views on programming styles ranging from very old school, constantly questioning the need for object orientation, through to very modern, arguing for progress and trying to keep everybody up to date. We adopted unit testing around two years ago and, although the overall development process takes a little longer, I think everyone agrees that it's more than proved its worth. In general we have written our unit tests after we have written our code but, for me, it has never really seemed like the correct or logical way to do it so recently I have been trying test-driven development and I have found it to be quite useful. I guess really I am keen to know what other people think about the whole approach to unit testing.
Test immediately after writing (I should do test first but I find running a test to fail because I haven't written any code yet is a bit of a mind set change) However - how many contributions to Codeproject include the unit tests? maybe that should be a suggestion?
'--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
-
What do you do for the functions you can't write tests for (i.e. ones that depend on specific external conditions?). For example, imagine a function that took a URL, fetched the page, and returned the contents of the page. How would you unit test that?
In those cases, you would write a Mock object that returned a facsimile of the output. Mocking is great because it allows you to break the heavy coupling that typically goes into a project.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
-
In those cases, you would write a Mock object that returned a facsimile of the output. Mocking is great because it allows you to break the heavy coupling that typically goes into a project.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
The original code (let's assume) makes a request over the network. Are you suggesting removing that code to do the unit test?
-
What do you do for the functions you can't write tests for (i.e. ones that depend on specific external conditions?). For example, imagine a function that took a URL, fetched the page, and returned the contents of the page. How would you unit test that?
If you know what the page should look like you could simply fetch it into a string and compare it. I have a bunch of shared code that, amongst other things, includes some cross-platform socket classes which I test in a similar way. I supply a special config file to the unit test framework that contains host names, etc. that I need when the test runs. For example, I have a class that logs into a POP3 server and checks the mail count and the mail server/user/password details are supplied in this config file. Some frameworks also allow you to create 'mock objects' - for example a 'pretend' HTTP stream that you could feed into your test code, etc. The Boost stuff I use isn't that advanced, but I believe that mock object frameworks are available for C#/Java/etc.
Kicking squealing Gucci little piggy.
The Rob Blog -
Hi everyone, I'm curious about other peoples views on unit testing. The company I work for is quite small and there are only four full time developers. We all have different views on programming styles ranging from very old school, constantly questioning the need for object orientation, through to very modern, arguing for progress and trying to keep everybody up to date. We adopted unit testing around two years ago and, although the overall development process takes a little longer, I think everyone agrees that it's more than proved its worth. In general we have written our unit tests after we have written our code but, for me, it has never really seemed like the correct or logical way to do it so recently I have been trying test-driven development and I have found it to be quite useful. I guess really I am keen to know what other people think about the whole approach to unit testing.
To be honest - while there are some issues with writing Unit Tests up front, I am now a big fan of TDD. Having started using it about 2 years ago, I find that I now automatically think in that direction. However, a word of warning for those who write Unit Tests. It is vitally important that you think about the tests that you apply to your code. It's all very well having unit tests, but if they don't exercise the code you are testing or they leave large parts untouched, the unit tests are worthless. Unit Testing is easy - being able to write good unit tests is a much more difficult beast.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
-
The original code (let's assume) makes a request over the network. Are you suggesting removing that code to do the unit test?
Not at all, although I wouldn't normally attempt to retrofit Unit Tests into code. The way I normally work is to develop loosely-coupled code, where I use interfaces to define what needs to be done. Then, I mock up the objects based on the interfaces. Take the classic example of wanting to update a database. In order to have repeatable tests, I would create an interface for the database update - this would then be mocked to simulate the update. I would then run my unit tests against this mock. Lo and behold, I've got code that I can retest.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
-
To be honest - while there are some issues with writing Unit Tests up front, I am now a big fan of TDD. Having started using it about 2 years ago, I find that I now automatically think in that direction. However, a word of warning for those who write Unit Tests. It is vitally important that you think about the tests that you apply to your code. It's all very well having unit tests, but if they don't exercise the code you are testing or they leave large parts untouched, the unit tests are worthless. Unit Testing is easy - being able to write good unit tests is a much more difficult beast.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
Indeed, and obtaining anywhere close to full coverage is no mean feat!
Kicking squealing Gucci little piggy.
The Rob Blog -
Not at all, although I wouldn't normally attempt to retrofit Unit Tests into code. The way I normally work is to develop loosely-coupled code, where I use interfaces to define what needs to be done. Then, I mock up the objects based on the interfaces. Take the classic example of wanting to update a database. In order to have repeatable tests, I would create an interface for the database update - this would then be mocked to simulate the update. I would then run my unit tests against this mock. Lo and behold, I've got code that I can retest.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
So how do you unit test the network access code in my example?
-
If you know what the page should look like you could simply fetch it into a string and compare it. I have a bunch of shared code that, amongst other things, includes some cross-platform socket classes which I test in a similar way. I supply a special config file to the unit test framework that contains host names, etc. that I need when the test runs. For example, I have a class that logs into a POP3 server and checks the mail count and the mail server/user/password details are supplied in this config file. Some frameworks also allow you to create 'mock objects' - for example a 'pretend' HTTP stream that you could feed into your test code, etc. The Boost stuff I use isn't that advanced, but I believe that mock object frameworks are available for C#/Java/etc.
Kicking squealing Gucci little piggy.
The Rob BlogSo you're not testing the network access code, just bypassing it, and putting fake results in the output?
-
So you're not testing the network access code, just bypassing it, and putting fake results in the output?
In my case no, as I am not using mock objects. My code is actually connecting to a known POP3 server over the network, logging in using a known user/password, etc. and all the responses I expect to the POP3 commands are pretty much fixed. For example, when I connect to the POP3 server I use, I know the response will be something like:
+OK Qpopper (version x.x.x) at HOST starting.
When the code I'm testing issues a USER command, I know the response should be:
+OK Password required for USER.
etc. etc. The important thing is to break your code up into small, easily tested functions rather than trying to test monolithic code that consists of thousands of lines. This makes life much, much easier.
Kicking squealing Gucci little piggy.
The Rob Blog -
So how do you unit test the network access code in my example?
If we follow the TDD approach, then I would mock this up so that the Mock object represented the network access. In other words, I might have an interface called INetworkAccess which I mocked up to represent the access. My test would then test the object which relied on INetworkAccess which would verify whether or not this code worked independent of the network access. Now, you will also need to test your physical network access code, so I would also mock up an object that you could guarantee would be there 100% of the test time. Your network access code would then be tested against this object. By doing all of this, you've broken the testing apart so that you can test code in isolation without having to rely on outside factors. I would really suggest that you take a look at frameworks such as RhinoMocks and areas such as Test Driven Development. They do take some getting used to, but once you are used to them you will find that they really do help.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
-
Indeed, and obtaining anywhere close to full coverage is no mean feat!
Kicking squealing Gucci little piggy.
The Rob BlogRob Caldecott wrote:
Indeed, and obtaining anywhere close to full coverage is no mean feat!
Sometimes you have to accept that you can't get 100%. You can become obsessed with generating absurd test cases just to get to a line of code, the development loses focus and the project slips.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.