being Test Enginner myslef and having the same problem to persuade and educate developers how to write testable code I find your presentation very nice. Is it OK to use your slides?
Good points! The tests are and should be easy. The whole point is to make the code testable in much the way you described. About those static calls in Java: is it really not possible to use import statements as seams ? In Working effectively with legacy code it's suggested that linking against a fake library (C++) could be used to break such dependencies?
Nice work! I like the push for unit testing. I encourage you to push for test-driven development as well: having developers write the unit test before any code is written (when possible or practical). This has made my life *so* much simpler.
The car metaphor didn't work for me. I recommend you use an example that's easier for developers to relate to, like a typical web application stack (headless or with a UI).
Finally, and for what it's worth, I feel like I've had a lot of success when I develop all my classes as plain old Java Beans: no argument constructors and setters for everything that needs injecting. I avoid constructor args as I find that leads to the "Long Parameter List" code smell.
I prefer constructor injection over setter injection since compiler makes it clear to me in which order I need to instantiate things. It also allows me to make objects immutable.
If your constructor becomes too long, than yes it is code smell. Perhaps your class has too much responsibility? Perhaps you are mixing concerns? Don't blame the constructor, the dependencies are there, constructor just makes them painfully obvious.
Misko, Thanks a million for this talk. You mentioned influencing someone miles away. You sure did, influence me right here in India, and almost 3 years after your talk!!. I have learnt so much about better unit testing through your talk.
How can this be applied to applications where the business logic decides which objects need to be created? For example, let's say I have business rule of the form which states "create a creditor object" when "the customer is delinquent in an amount greater than $100"? The problem is that the knowledge of whether or not to create the creditor object cannot be isolated from the business logic.
This approach assumes that a static program graph can be created in advance, but what happens when the business logic is required to create the graph? For example, let's say we have a business rule that translates to "create a collections object when the customer is past due in an amount over $100.00"? Often the two are inherently intertwined.
Good Job. Thanks!
ResponderEliminarfrom this s/w test engineer... thanks, this give us plenty to think and talk about this week.
ResponderEliminarAre these tech talks auto-downloadable as a video podcast? if not, please pass along my suggestion that they be, they're great.
Hi,
ResponderEliminarbeing Test Enginner myslef and having the same problem to persuade and educate developers how to write testable code I find your presentation very nice.
Is it OK to use your slides?
Yes, the slides are posted for the world to use. Nothing would make me happier than influencing someone miles away.
ResponderEliminarGood points! The tests are and should be easy. The whole point is to make the code testable in much the way you described.
ResponderEliminarAbout those static calls in Java: is it really not possible to use import statements as seams ? In Working effectively with legacy code it's suggested that linking against a fake library (C++) could be used to break such dependencies?
Nice work! I like the push for unit testing. I encourage you to push for test-driven development as well: having developers write the unit test before any code is written (when possible or practical). This has made my life *so* much simpler.
ResponderEliminarThe car metaphor didn't work for me. I recommend you use an example that's easier for developers to relate to, like a typical web application stack (headless or with a UI).
Finally, and for what it's worth, I feel like I've had a lot of success when I develop all my classes as plain old Java Beans: no argument constructors and setters for everything that needs injecting. I avoid constructor args as I find that leads to the "Long Parameter List" code smell.
Again, nice work and I look forward to more!
@whateverdood
ResponderEliminarI prefer constructor injection over setter injection since compiler makes it clear to me in which order I need to instantiate things. It also allows me to make objects immutable.
If your constructor becomes too long, than yes it is code smell. Perhaps your class has too much responsibility? Perhaps you are mixing concerns? Don't blame the constructor, the dependencies are there, constructor just makes them painfully obvious.
Excellent article!!!
ResponderEliminarCongrats Misko not only for the excellent subject you touched but for being a great speaker as well.
ResponderEliminarI also vote for the video podcast!
Please make it happen :)
Misko,
ResponderEliminarThanks a million for this talk. You mentioned influencing someone miles away. You sure did, influence me right here in India, and almost 3 years after your talk!!. I have learnt so much about better unit testing through your talk.
How can this be applied to applications where the business logic decides which objects need to be created? For example, let's say I have business rule of the form which states "create a creditor object" when "the customer is delinquent in an amount greater than $100"? The problem is that the knowledge of whether or not to create the creditor object cannot be isolated from the business logic.
ResponderEliminarThis approach assumes that a static program graph can be created in advance, but what happens when the business logic is required to create the graph? For example, let's say we have a business rule that translates to "create a collections object when the customer is past due in an amount over $100.00"? Often the two are inherently intertwined.
ResponderEliminar