Obviously testing software before it is released to the masses is important. Testing is also a great way to verify project requirements and in some extreme cases, drive the entire development of an application. When you start thinking about large web applications that operate in a distributed environment and service a large number of clients - testing should be the first thing that comes to mind. However, it seems that in certain cases, the size and complexity of enterprise applications make testing a resource intensive, daunting task that gets ignored. As a naive enterprise developer, I set out this past week to investigate the various testing strategies and break the testing stigma that plagues smaller enterprise development boutiques.
From the research I conducted, the most popular approach seems to be making use of mock objects during development. Since most web applications require interaction between multiple components or services it is often hard to write a test case for an individual component without first implementing all collaborating components. The basic principal behind mock objects is to provide basic, functional collaborating objects without disrupting the task at hand. Aside from being useful during development of an individual component, using mock objects also allows you to perform additional testing on the component without impacting live data or configurations (this is handy for verifying requirements). The mock objects approach promotes the use of a factory design pattern to provide a single point of entry for "mock" components. As someone who is new to the enterprise scene, this concept took a while to understand. I hope that all the work I spent digesting this information pays off when I take my very first web app from soup to nuts.
