Usually, when a team/person is building a website or web application, the usual process is a Top-down design. Means you start with the initial specs and work your way through the process making sure every piece of code is written in accordance to the "plan".
What an elegant process isn't it? But as we will see lately why, Top-down process doesn't makes sense in many real-world scenarios when you are writing a web application, here is why:
- Web technologies evolves very fast - new database technology, internet devices is being introduced almost every month. One great example of this is the introduction of NoSQL databases, before that, all developers was religiously sticking with RDBMS, now here comes the scalability issue and boom!, every serious web app moves to Hadoop. It goes w/o saying that before, there is no such thing as tablets, iPod, PSP, Internet TV - these stuffs are game changing devices since they are consuming the web in one way or another in the form of podcasts, online games and etc.
- Business logic could change anytime - marketing guys will somehow think of another strategy to do their business plans, better SEO methods, whitelabeling of someone else's products, affiliate marketing -- the list goes on. But one thing is for sure, businessmen will continue to outwit each other by formulating better business plans. For us programmers, this means we need to change our code often to keep up with those plans.
- Most of the business owner doesn't really know what they really wanted -- yes, specially those business owners that has no really technical background or lacks the capability to organize their goals. I encountered many of these, people who kinda makes the software itself as their "brainstorming place" by defining very broad goals, not setting a concrete plan and sending out the programmers and just sending out additional ideas along the way (which often contradicts to the initial idea)
Given those scenarios, if you are following a Top-down design paradigm, your software will either turned out to be a spaghetti code or it will be a just another incompetent software like any other else (not extensible, unsecured, fragile). Usual reason for this is a sudden business logic shift, forcing the code base to perform something it was not intended to do at the start of the project.
Though this process works for smaller projects, which usually takes only days or weeks of development, problems appears when the following factors was included in the scene:
- multiple developers is working in the same project
- project needs to both scale out and scale up due to high traffic
- needs to support different 3rd party services
- changes to business logic is almost everyday
There is an emerging workflow to solve this problem, called Agile Method. But man, that is the workflow, lets talk about the coding process itself -- Test Driven Development.
Ok, so what is this TDD thing?
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally re-factors the new code to acceptable standards
The keyword here is "very short development cycle". Means you don't dive straight through building the whole software and then check with the stakeholders if that is they wanted.
Doesn't wastes your effort and time
In TDD, you just write the Tests (business logic), then writes the minimal code that will satisfy that tests. This code can be full of stubs or any forms of codes that can be re-factored later when the business logic is "final".
The primary advantage of this is, you don't waste your time spending hours of making a fully functional software just to know in the end it will not be needed anymore since the business owner had "changed it mind".
Makes you sleep tight at night
Admit it, there are many instances that you were woke up by your client yelling at phone saying their site is broken due to some changes you did earlier in that day. Well, for someone who has been tired for the long day of coding and debugging, its almost impossible to manually test each and every aspect of the whole web application. That is something should be done automatically isn't it?
That is TDD is very good at, it gives you some level of confidence that no matter what change you did in the system, you just run the Test Suites, it will check all and every Tests (Unit Tests, Functional Tests, Integration Tests, Acceptance Tests) making sure you haven't accidentally broken some feature in the web application.
Allows you to write a pre-made reusable libraries which allows Rapid Application Development
In all web applications, there are things that is always common to all of them, whatever the business logic is, there is functionality that is for sure will be always there. Like for example in any website, there is always logic for authentication of users, or logging of visits for custom analysis etc. These things can be made in advanced and put in your arsenal for future use. The biggest challenge for that though is, how can you assure those individual components is working fine w/o plugging into a real application?
The answer to that is Unit Tests (one of the many kinds of TDD Tests). This allows you to test the individual classes to make sure those are working as expected before you even plug it into a real application. This are very effective method when you are developing Composer Libraries.
Once you had developed your common business logic in its own individual libraries, you can easily require it in your composer.json to make it available in your application.
Those are the clear advantages of embracing TDD at the core level, but there is a deeper reasoning about that as well when you come into the field of good software engineering -- eg. Inversion of Control (IoC), Dependency Injection etc. But those are complex topic for this post and probably a subject of my future posts :-)
Did you find this useful?
I'm always happy to help! You can show your support and appreciation by Buying me a coffee (I love coffee!).