Test First , Test Last or Test At All?
-
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.
-
Rob 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.
-
Well - a private function must be there to satisfy a purpose. It shouldn't exist in isolation. Your testing of the exposed surface should attempt to exercise them. If you can't get at them though, it would suggest to me that they are layered too deep (e.g. you have lots of if/else conditions that need to be satisfied to get to them). That normally suggests, to me at least, that there is a more fundamental problem with the design.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
-
Take the Microsoft option and get your users to test it after release.
Who peed in your oatmeal today?
Software Zen:
delete this; -
Possibly, but I'm not too interested in the finer details. i just wanted a bit of an informal discussion about other people opinions.
:) I think as a genuine case, even the Lounge Police seems to have accepted this as an exemption, considering the amount of bona fide responses that the thread has recieved. ;)
Vasudevan Deepak Kumar Personal Homepage Tech Gossips
-
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.
-
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, schmest. If it compiles, ship it! Or even better, use some interpreted programming language so it doesn't even need to compile.
-
Test, schmest. If it compiles, ship it! Or even better, use some interpreted programming language so it doesn't even need to compile.
Is this the "Testing is for wimps. We make the big bucks in the support contracts" mindset?
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
-
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.
Ship the software and let the users discover the bugs for you. After all, God put users on this planet for a reason.:laugh:
-
Ship the software and let the users discover the bugs for you. After all, God put users on this planet for a reason.:laugh:
Vivic wrote:
After all, God put users on this planet for a reason.
Two words. Legitimate Targets.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
-
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
By coincidence I was thinking about this the other day... :->
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
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:
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.
are you sure you don't work in my department and on my team?
chambers-chris wrote:
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.
I guess not. :laugh: Honestly, I love test driven development, and unit tests. if you can't be TDD at least have regression tests and validation tests. But alas, I can't get anyone to sign on to even those... :((
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
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.
It's been a long time since I've done any complex programming, but the old school way always worked well for my projects. Start with a spec. Write a test procedure to verify the spec. Define sub-specs for each module, and test procedures for each. Define interfaces between modules and enforce them with real change control. Design and code the modules, then test them individually. Correct as necessary until the spec is satisfied and the interfaces with other modules are verified. Integrate two or more modules and test again. Integrate the entire project and test some more. Give it to a user and watch him/her break it in a wholly unanticipated way.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"