Software Engineering

Monday, October 16, 2006

Benefits of Architectural Frameworks

If you haven't heard of architectural frameworks, then allow me to enlighten you on a fairly new concept that will save you time and energy. Architectural frameworks, also referred to as microarcheticures, are frameworks that provide software engineers with a skeleton (the architectural design) to which to add meat to (or business logic). They are typically composed of a collection of object oriented design patterns that work together and they do not impede the impede creativity. However, architectural frameworks DO TAKE THE BRAINWORK OUT of the architectural aspects of software development leaving your creative neurons fresh to think more about the other aspects of software development. Microarchitectures also promote consistency in the architectural design pattern and
rapid development.

One great example of an architectural framework is the Cairngorm microarchitecture. The Cairngorm microarchitecture is used by Flex developers to create Flex applications that are highly scalable and maintainable. Cairngorm is also developed as an open source project with Adobe Consulting as the lead. If you would like to invest in learning this architectural framework, then here is a good place to start:

Once an Architectural Framework is learned, it allows you (software engineers) to get more done with less effort.

If you know of any other good microarchitectures, then please post links to them in your comments.

Tuesday, August 01, 2006

A Mockery of Mock Objects

Mock objects are emulations of real objects except without any implementation. These emulations have their outputs already defined before they are used. Typically unit tests that utilize mock objects will use them to mock various contingencies such as: emulating a specific interaction with the tested object, and setting up test return values on initialization objects. Mock objects seem appealing and catchy at first, but if you really think about it they aren't very useful. Don't waste your time learning Mocking Frameworks.

A lot of people would argue that one must mock an object because the real object is too difucult to initialize and setup for a unit test. Well, really if it is that difficult to set up, then one should refactor the real object so that it is simple to use. After all, simplicity is what we are all after when designing an object model anways, isn't it?

Another problem I have seen from very intelligent software engineers is that they get over enthusiastic about mocking objects. I have been on a team where the software engineers literally forced a test to pass by mocking too many objects. They mocked too many objects within the unit test forcing it to pass. It was like a teacher handing you a test with all the answers already filled in for you! The test did not test anything; it was set up to pass before it even ran! Needless to say the test passed, but there where numerous errors in the code.

Mocking object interactions is actually the root of the problem. When one mocks an interaction, then regression testing is no longer possible. For example, lets say you have an object A that object B implements internally. Object B calls a method of object A. In Object B's unit test, object A is mocked and the method called is set to return a value X. Object A's method implementation is now changed to return a new value Y. Since object B has mocked object A and its return value has been mocked, then object B's unit test still passes with flying colors! Object A's unit test will also pass with flying colors. But, the real applicaiton will fail. This could have been prevented if no mock objects were used.

Additionally, for those that feel like they "need" to mock objects for a particular situation, I can show you how to reproduce that situation without mock objects. Whenever you feel like you need a mock object you are developing code that is not testable or you are just being lazy.

The problem with mocking objects is that issues between object interaction passes by the "Daily Build and Smoke Test", or continuous integration, undetected. Because issues between object interactions aren't detected during continuous integration due to mocking interactions, then that means these issues won't expose themselves until functional/acceptance testing. By this point it is too late in the game! It is too late because typically acceptance tests are ran at the end of the iteration which could be thirty business days! Now, you have thirty business days worth of code to sift through in order to find the bug. If your lucky the bug will be detected at runtime during acceptance testing, but again too late in the game. Waiting for acceptance tests to catch problems with object interactions is just too late and unacceptable!

For more information and discussions about avoiding mock objects, visit these related posts (I will add more links to related articles as I find them. If you have any comments or links, then please feel free to add them to the comment section):

Thursday, April 14, 2005

Eliminate Off-By-One Errors For Good!


One of the most common programming errors is the off-by-one error. The Off-By-One error ...


Make all compilers limit programming language elements to one-based. Of course, old code will be identified and handled appropriately. Being consistent will prevent a lot of trips to API documentation and significantly decrease the number of bugs that occur in code.

Monday, April 11, 2005

AI Machines Need God's Law