In your book, I am not sure if I understand this correctly. You talk about sometimes to write tests that need to refactor existing code. Also, it states that with mock objects makes developer think differently about the code and about design patterns? Do you mean because mock objects may require refactoring then may lead to design patterns to solve the problem.
Actually, in order to design mock objects properly, you will often find that you have to refactor existing code. Mock objects should be pretty dump. You give them an interface and "program" them to reply in a certain manner. THen, when they are called, you always know how they are going to respond. You can then test your application to make sure it responds appropriately. L
Originally posted by Jean Miles: In your book, I am not sure if I understand this correctly. You talk about sometimes to write tests that need to refactor existing code. Also, it states that with mock objects makes developer think differently about the code and about design patterns? Do you mean because mock objects may require refactoring then may lead to design patterns to solve the problem.
Yes, when you write tests using mock objects, you'll often find that you need to refactor the code under test so that you are able to introduce the mock objects into your code during testing. This is a good thing because it usually leads to code of better quality (i.e. code more flexible, with less ties to the rest of the code). In addition, the tests are a first class user of the code under test and as such you'll often discover flaws in your API design when it is first used.
-Vincent<br /><a href="http://www.manning.com/massol" target="_blank" rel="nofollow">JUnit in Action</a> author
I'd like to add that when you start writing mocks, you'll probably get that "why am I doing all this stuff" feeling often. Once you start seeing the remarkable benefits in a more decoupled form, you'll get the reward.
It really takes alot of work to create tests, I see all the benefits but it is hard to explain to project leads that if this is the first time we are create tests for code and takes a learning curve to understand what we are doing, but in time it will cut the time in testing changes introduce throughout the project.
Joined: Jan 23, 2002
Would it be possible not to tell the project lead -- isn't it up to you how you write code...? Seriously, I'd simply start writing tests (even if it was just for my private environment) and keep an eye out for my speed. Then, if it would look like I'm falling behind schedule, I could easily give up writing tests and revert back to the old way of doing things. After one or two projects, you won't be falling behind schedule because of a learning curve.
Originally posted by Jean Miles: It really takes alot of work to create tests, I see all the benefits but it is hard to explain to project leads that if this is the first time we are create tests for code and takes a learning curve to understand what we are doing, but in time it will cut the time in testing changes introduce throughout the project.
There are different ways of doing it. One of them is to explain that typing code is only 50% of the work when developing an application. The other 50% is testing the code you've typed. You'll have to test it anyway (nobody will contradict this). Then you have 2 solutions, either you write some informal tests (like a quick main method, or simply deploy and start up the application and enter data, navigate menus, etc) or you write formal tests. Informal tests are lost and when you need to run them again (for example to test against regression) they are lost and you need to write/run them again manually. Thus what you need to demonstrate is that a good framework like junit (and extensions) lowers the barrier to writing automated tests. In due time, the cost is about the same as the manual tests but the advantages are tremendous as you can run them as often as you want to verify nothing is broken. Now WRT to the training period, your manager need to bite the bullet. You can tell them that a single bug that makes it way to production will cost as much as spending tens of men day learning/writing tests. And when writing these tests you are 100% *sure* to find several of these bugs. Then I guess it's a matter of asking for a proof of concept of some portion of the code, writing tests and showing that it's not that hard and how well it works. Anyway, I know it can be difficult. However, in my past project I've never found any difficulty in convincing the managers. The only problem I've had is convincing them to give us the budget for these tests... So I usually start with a minimal lightweight testing strategy (we don't test everything and not all types of tests) and improve it incrementally across iterations. What you absolutely need to do is include the time for writing these tests in your task estimations. If you separate testing time from coding time, you're in for trouble as manager may think testing is optional. And some developers may also think this... Good luck!