Home » Software Architecture » Software Architecture without Test Driven Development is DANGEROUS!

Software Architecture without Test Driven Development is DANGEROUS!

TDD Impacts Software ArchitectureI’ve had two incidents recently that have shown me how TDD impacts Software Architecture.  Both of these are with code I’m working on.

What Software Architecture Might Do

Software architecture might specify how is put together at a very high level.  For example, software architecture might specify that we use a three tiered approach or an n-tiered approach.  This approach places our view code is at one level, our business rules are at another level, and our data access at yet a third level.

Software architecture might specify that we use MVC where our business rules are in the model, and a controller communicates between the view and the model to get data between the two.

It might specify MVVM. This would have the view model take the place of the controller and manage the state information for the view.

Software architecture might also tell us we should use MVP, giving the presenter the role of the controller and managing state information for the view and communicating with the business rules.

But none of these patterns tell us how to write maintainable code.  They only tell us about the general software architecture.  This is like having a sketch of a house without a wiring or plumbing plan.

When the view gets in the way

So, if you’ve been following this blog for a while, you may remember that I’m working with EXTjs.  Specifically, I’m working with EXTjs 4.2.  This has what Sencha calls an MVC architecture.  The problem is, what they refer to as the “Model” we would all recognize as a “Record” in a table, and their Controller is tightly coupled to their View.  That is, they call this MVC, but no one who understands what MVC is supposed to look like as a design pattern would recognize Sencha’s MVC as the real MVC design pattern.

This makes the code incredibly hard to test.  The tendency is to write code that is highly dependent on the view.  The view is dependent on the DOM.  Rendering the view takes quite a bit of time.  So any test of your business rules end up taking an incredibly long time to test because they ultimately cause DOM manipulation to occur.

It isn’t until you decide to borrow a bit of architecture from Angular that you realize that your business rules should be separate classes.  Angular has “Service Classes.” My Service classes are built specifically so they do not rely on anything else.

By doing this, I was able to get two thirds of my code under test that run in about a second.  Prior to this, they took a half an hour.

My next task was to get the view and my logic for enabling and disabling controls on the view more loosely coupled.  This was a bit more difficult because enabling and disabling controls is, naturally, a view thing.

But again, taking a page from another framework, this time Knockout and Angular, I created a ViewModel.  My ViewModel holds the state of my view separate from the actual view.  When the state changes, it fires an event that actually changes the view, but this will allow me to test my enable/disable logic, along with other code in my system, without ever instantiating the view.  Under test, the events will fire and nothing will happen.

Avoiding Dependencies

Now the structure  of my code looks something like the following:

View – ViewModel – EnableDisableController – EnableDisableService

I could have put the EnableDisableService code in the EnableDisableController, and many people would, but what I’ve found is that if I do that, it would be nearly impossible to UNIT test my Enable/Disable logic.  Why?  Because I would be creating all of the objects I needed for the logic in the same class the logic is in.

By breaking the logic code into it’s own class that takes the ViewModel as a construction parameter, I can create my own ViewModel that looks exactly like what I need it to look like so that I can test the logic with entirely known values.

These are just two of the ways that code architecture is impacted by Test Driven Development.  I’m sure there are others.

How have you found TDD helps improve your software architecture?  Leave me a comment below.

 

Other Places Talking About TDD and Software Architecture

 

Other post in Software Architecture

Related Post

  • YAGNI – You Aren’t Going To Need ItYAGNI – You Aren’t Going To Need It One of the design principles in software development is to only write what you need today.  This has taken on the moniker of YAGNI (You Aren’t Going To Need It). The question is, […]
  • ASP.NET MVC – Model != BLL or DALASP.NET MVC – Model != BLL or DAL Last week I introduced the ASP.NET MVC framework by talking a bit about what the model, view and controller are. In the comments, John Meyer said, I respectfully disagree with your […]
  • Dependency Injection Frameworks Are NOT Dependency InjectionDependency Injection Frameworks Are NOT Dependency Injection As you start your journey down the road of Unit Testing you will discover that part of what makes code testable is this concept of Dependency Injection.  As you explore further, you […]
  • Automated Web Application Functional TestingAutomated Web Application Functional Testing One problem we often have when performing application test is that if we are testing  applications that modify the database in some way, we can’t test without modifying the […]
  • JavaScript MVVM – You’re (Probably) Doing it WrongJavaScript MVVM – You’re (Probably) Doing it Wrong If you are using one of the many frameworks that say they are using JavaScript MVVM, you might not be using it the way it should be used. Many of my clients aren't. This article will […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS. Does your team need additional help in any of the above? Contact Dave today.

One Pingback/Trackback