As a Backend developer, how do you approach HTML Mockups?

Question

I've searched within the site, but couldn't find my answer..

I'd like to start a project from ground up, and my customer has given me a HTML Mock-up of the product and asked me to do it in a TDD approach.

Normally, I was responsible for designing and developing both front-end and back-end parts, and it's my first time that they have given me the mock-ups. It's not my favorite style of developing software for consultation works (I normally start by Model layer, then View, and then Controller for integrating them.)

So my questions are:

1- Basically, how should I attack the problem? I know that it is better that I have the View Layer,but I want to adapt the View into my favorite Template Language of choice.

2- I have to do in a TDD approach. I guess having MockUp is a perfect scenario for "Functional Testing" by using Selenuim test tool, for instance. Am I right ??

Answer 1

The short response is:

1. write a definition of your problem as formally as you can
2. choose one or more testing frameworks and write your tests; simplifying:
   1. unit tests for backend
   2. functional tests for frontend
3. start looping: design, code, test
4. periodically review with committer

You can use every View Technology you want to realise your mocks. It's HTML...

Being more verbose, HTML Mockups are great to help you define use cases (UCs) and business requirements (BRs). From UCs and BRs you'll be able to define a first draft o full requirement specification and a system and architectural design from developer (your) perspective.

Every functional requirement in BRs, should have a functional test, runnable using for example Selenium you mentioned, and should be exploded into several fine granularity requirements, for each of which you can define a unit test. Following a TDD approach then you can build your backend trying to pass every unit test and, rolling up, every functional test.

When you complete your single BR's backend, you can concretize the correspondent html mock in your preferred view technology and run functional tests in your technical environment and then in an integration environment.

These tests can be done automatically using continuous integration.

When every BR of a UC has passed its functional test and unit tests, you can submit the use case to you committer for user acceptance and have feedback.

Every step should consider a loopback up to the design phase. If you keep trace of every dependence among UCs, BRs and unit tests (for example using a traceability matrix in a Spreadsheet), the you should be able to indentify and limit loopbacks impact and act with code changes to limited code base.