Where to start with the development of first database driven Web App (long question)?

Question

I've decided to develop a database driven web app, but I'm not sure where to start. The end goal of the project is three-fold:

1. to learn new technologies and practices,
2. deliver an unsolicited demo to management that would show how information that the company stores as office documents spread across a cumbersome network folder structure can be consolidated and made easier to access and maintain and
3. show my co-workers how Test Driven Development and prototyping via class diagrams can be very useful and reduces future maintenance headaches.

I think this ends up being a basic CMS to which I have generated a set of features, see below.

1. Create a database to store the site structure (organized as a tree with a 'project group'->project structure).
2. Pull the site structure from the database and display as a tree using basic front end technologies.
3. Add administrator privileges/tools for modifying the site structure.
4. Auto create required sub pages* when an admin adds a new project.
   4.1 There will be several sub pages under each project and the content for each sub page is different.
5. add user privileges for assigning read and write privileges to sub pages.

What I would like to do is use Test Driven Development and class diagramming as part of my process for developing this project. My problem; I'm not sure where to start. I have read on Unit Testing and UML, but never used them in practice. Also, having never worked with databases before, how to I incorporate these items into the models and test units?

Thank you all in advance for your expertise.

Answer 1

I have the feeling that you are trying to grab too much at once. It is fine to experiment with databases, TDD and UML diagrams; that in itself would IMHO be enough for a single project. This first experimental project will teach you a lot, based on which you will be able to do a much better job on the next project. But I would not expect this first try to bring results which can convince other developers to pick up TDD, and/or management to change its way of thinking. You need to understand and experience things at first yourself, before you can reasonably explain them to others.

For advice on unit testing DB apps, see these threads for starters:

• What’s the best strategy for unit-testing database-driven applications?
• Unit-Testing Databases
• Unit tests framework for databases
• Testing approach - DB, Junit

I am not sure what you mean by "prototyping via class diagrams". Class diagrams are fine for discussing / communicating your design to other developers, and should certainly be in the toolkit of every good developer. A whiteboard session with someone, sketching and erasing design elements on the fly is a great way to clarify the design and the forces influencing it. However, IMHO this is "prototyping" only in a very broad sense. A real prototype to me is code - that is the only way to verify whether or not your design really works in practice.

Answer 2

I'm not sure where to start.

We always start with the data model.

having never worked with databases before, how to I incorporate these items into the models and test units?

Ah, well, there's the problem.

You have to start with the data, because everything starts with the data.

1. Write use cases. Your 5 technical requirements aren't really very good use cases because there's no Actor who interacts with a system. You need to write down the things an actor does -- what the actor interacts with.

2. Identify the objects that the actor interacts with. When in doubt, write down all the nouns in your use cases.

3. Draw a picture of the classes that will implement those objects.

4. Walk through your use cases to be sure that all the things an Actor needs to do are based on attributes of your class definitions. All the data an actor needs has to be in these classes, which will become tables in your database.

Now, you have to start doing more technical work. You need a web framework with an ORM layer. You're using PHP, so you'll have to find a good framework for this. Cake or Doctrine or something.

1. Define one class in your ORM layer. You don't have to be complete or precise, you just need something that you can test with.

2. Write unit tests for this class to be sure that it has the right data elements. This will be relatively simple at first, since your individual data classes will start out simple.

Once the basic set of classes are defined, you'll need to look at relationships among classes. This is where the real work starts.

1. Look at a relationship in your picture. Any line. Pick one randomly.

2. Write unit tests to be sure that you can "navigate" across that line. From one object, fetch the related objects at the other end of the line. This shouldn't be very complex, just a few lines of code.

3. Create a "fixture" -- test data you can load into a database -- to represent the objects and their relationships.

4. Run the test. If it breaks, update your ORM definitions to support the navigation properly.

When you've finished doing all the various relationships, you will have built a reasonable complete data model in a Test-Driven manner.

Now you can build your PHP presentation for the model objects.