Assigning Responsibilities

alecl — Mon, 14 Jan 2008 15:04:00 GMT

It’s All about Assigning Responsibilities

This example really hit home for me. I am faced with a very similar legacy code design where some processing takes place and an e-mail is sent out. My current tests consist of integration tests that outright send me an e-mail that I have to confirm manually. Having these tests was far better than nothing at all, but their design never sat well with me. They were from an earlier attempt at writing tests before I truly understood or had time to delve into IoC, mocks or refactoring for testability.

Now half a year after having written the tests, I understood that I could use a mock to determine if an e-mail was sent without sending an actual e-mail. But how would that help me determine if the contents of the e-mail were correct. After reading Jeremy's article it became clear that my code design itself was flawed and I need to simply separate the generation of the e-mail text from sending the e-mail. It's such a simple idea and makes so much sense.

Share this post: Email it! | bookmark it! | digg it! | reddit!

Promises and Paradigms

alecl — Sun, 25 Feb 2007 22:37:00 GMT

I've always tried to make it a point to read a lot about the industry and constantly shifting and improving methods and best practices. Sometimes the buzz dies down after a bit -- I was particularly amused to find people tired of the lofty promises of EJB and going back to basics with POJO. Other times it grows to a roar.

The promises of unit testing and refactoring were being extolled for a while, but I must admit it took some time and much reading for it to sink in. If you're smart enough to make tests to exercise your code cases properly and didn't miss anything, you probably would have handled all those cases properly when you were coding anyway, right? Perhaps, but what about changing that code 6 months from now? What about someone else changing that code? I must admit I find a certain comfortable simplicity in writing unit tests to exercise the boundaries and coverage of a piece of code. After doing a few, it starts to become automatic and not take as much time as you would think. It keeps you honest. Even the best programmers can be burned when making just a quick last minute change that wasn't expected to change another area of code, but invariably does and most people are terrible at methodically manually testing their code countless times. Too many habits of doing things the same way every time leads very often to surprised cries of "But it worked for me.". Unit tests also add a margin of comfort to refactoring. Too often we let bad code persist and create maintenance headaches for years because it's not well suited for automatic or manual testing.

So I'm starting to believe now and writing my unit tests where I can going forward with new code and adding them to existing code when making changes. As time goes on, existing code will be retrofitted for testing and testing code coverage will increase. I'm definitely still learning and experimenting on testing methods and will occasionally post snippets or ideas I'm working on.

Share this post: Email it! | bookmark it! | digg it! | reddit!

Alec Lazarescu's Blog : Refactoring

Assigning Responsibilities

Promises and Paradigms