Let’s talk a little bit development.  How do you know that you got it right?

There are two key parts to software development:  The first is instructing the computer what it is you want.  The second is validating you got it right.  One easy way to validate an application is to run it and confirm everything is working as expected.  This is called User Testing or Functional Testing.  Virtually all applications should go through this form of testing.  There are some things that can only be validated through some form of manual observation. Functional testing often is the best way to validate that the layout of a User Interface is correct, or how the application interacts with the user.

However, Functional Testing has its limits and drawbacks.  For starters, it is by definition labor intensive.  It requires a certain level of skill and knowledge to know what to test. One must know the appropriate inputs and the corresponding expected results.  Moreover, as changes are made to the system, the same tests need to be repeated.  With bigger more complicated projects, this is exponentially more difficult to accomplish.  Testing an in depth process may require: setting up a given scenario, walking through the functionality, and validating the outcome.  There is more often than not, numerous combinations of inputs and outcomes that need to be tested.  Even more difficult to test are background processes and calculations.  In some cases, these may be virtually impossible to test.  Some operations may be only testable during certain times of day. Even more frustrating, many well written applications have interdependent parts, changing one aspect of a program can have unexpected consequences in another.   Often fixing one bug introduces another.

So what is the alternative? The answer is to introduce automated unit testing.  Again, this does not remove the need for Functional Testing, but can save a lot of time.  How this works is simple:   an automated unit test is a small semi-detached program that is meant to validate a given facet of a program.   For instance, an application may introduce a proprietary formula, perhaps concerning forecasting or finance.  A given set of inputs may be provided, with a known expected outcome; this is a virtual laboratory for the application.  Writing a given test may not always be faster than running a Functional Test, often it is not.  But the advantage is that these tests can be run over and over again, often providing immediate notification if there are any components not working as expected.  These test are generally written with the application.  As the application grows, so does the number of tests.  This becomes more critical with the size of the application or team supporting it.  Some software consulting companies insist on Automated Unit Tests to insure that everything has been developed to spec.

The prmiary discipline of working with Automated Unit Tests is called Test Driven Design (TDD).   Working with TDD requires the application be designed in a particular way in order to make it testable.  The code pattern used is most often referred to as SOLID, Microsoft’s gold standard of software development.  SOLID provides important direction, such as separating Resources, Servers and Models.

So are there any drawbacks in working with automated unit test?  In short, “Yes.”  Working with Automated Unit Tests and doing right is generally expensive and complicated.  To be sure, there are tremendous benefits in supporting a properly developed TDD application; however, it is not for the faint of heart.   First, a large proportion of developers a not equipped to work using TDD.  Developers that do, come at a premium.  Additionally, writing the numerous tests, as well as validating their coverage and quality, generally requires a lot of time from a top developer. Because of the complexity and variety of TDD flavors, there are a limited number of individuals can immediately and effectively contribute to a team working with TDD.

The general complexities are easy to find.  While there are a variety of injection frameworks, the complexity of using them is a common stumbling point for developers.   At their best these frameworks are awkward and at their worst, they become practically unusable. A commonality of these frameworks is that the injection process is disconnected from its use.  It can become exceedingly difficult to trace through the code.

Another problem with most implementations of SOLID is that the models and the associated behavior are not only decoupled, but entirely disassociated.  Object types are generally arranged according to their abstract purpose: A ViewModel, an interface, a service; having nothing to do with task they are related to.

While the benefits of TDD are immense, many organizations are making the hard but rational choice to opt out.  Many have tried to simplify the development process within SOLID, and some have had moderate success.  These successes are limited by SOLID which is itself the problem.

Fortunately, Newayva has developed a new, innovative way of accomplishing the goals as SOLID with the Service Area Architecture Pattern (SAAP).  Where the SOLID methodology commonly suffers from being awkward and overly complex; SAAP is a natural and accessible solution.  It is easy to learn and maintain.  It produces testable code, with far less effort:

In this paradigm a service is essentially a program.  A container class provides the boundaries of a service.  Inside of the given container class are Model types, a Context class (used to access service behavior) as well as the Service definition.   The Context object is remarkably simple and intuitive. It eliminates the need of a third party injection framework.  SAAP’s intuitive nature allows most developers to get up to speed almost immediately.  The SAAP framework is designed to treat each service as a separate program, so related object types are defined in close proximity.

While the basic patterns of SAAP are already in use, the roadmap for a fuller development of the SAAP framework is bright. Soon SAAP extensions will have basic functionality that will far exceed most injection frameworks.  Most strikingly it is an intuitive and virtually effortless way of reflectively resolving service requests for a given application.  SAAP’s routing mechanism will streamline Web API provides, having the ability to facilitate multiple service method calls within a transaction as well as a natural way for managing security.

Sometimes making small changes can have a big impact.  Simpler is better. The SAAP framework is just one way Newayva streamlining software development.  Just wait to see what else we have in store.