*
The moose likes Testing and the fly likes Mock objects Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Testing
Bookmark "Mock objects" Watch "Mock objects" New topic
Author

Mock objects

Jean Miles
Ranch Hand

Joined: Aug 20, 2003
Posts: 53
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.
L Duperval
Ranch Hand

Joined: May 14, 2003
Posts: 63
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


Live Free, Live Happy
Vincent Massol
Author
Ranch Hand

Joined: Aug 09, 2003
Posts: 70
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
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Jean Miles
Ranch Hand

Joined: Aug 20, 2003
Posts: 53
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.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30586
    
154

Also, mock objects encourage you to program to interfaces. This makes your code more generic.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Vincent Massol
Author
Ranch Hand

Joined: Aug 09, 2003
Posts: 70
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!
 
 
subject: Mock objects