Applying TDD when the application is 100% CRUD

Solution 1:

"The only purpose of the app is basically to pull a list of contacts"

Okay. Test that. What does "pull" mean? That sounds like "logic".

" display them on a page"

Okay. Test that. Right ones displayed? Everything there?

" display a form to send a message,"

Okay. Test that. Right fields? Validations of inputs all work?

" and the like."

Okay. Test that. Do the queries work? Find the right data? Display the right data? Validate the inputs? Produce the right error messages for the invalid inputs?

Solution 2:

I am working on a pure CRUD application right now But I see lots of benefits of Unit test cases (note- I didn't say TDD)

I write code first and then the test cases- but never too apart- soon enough though

And I test the CRUD operations - persistence to the database as well.

When I am done with the persistence - and move on to the UI layer- I will have fair amount of confidence that my service\persistence layer is good- and I can then concentrate on the UI alone at that moment.

So IMHO- there is always benefit of TDD\Unit testing (whatever you call it depending on how extreme you feel about it)- even for CRUD application You just need to find the right strategy for- your application

Just use common sense....and you will be fine.

Solution 3:

I feel like we are confusing TDD with Unit Testing.

Unit Testing are specific tests which tests units of behaviors. These tests are often included in the integration build. S.Lott described some excellent candidates for just those types of tests.

TDD is for design. I find more often then not that my tests I write when using TDD will either be discarded or evolve into a Unit Test. Reason behind this is when I'm doing TDD I'm testing my design while I'm designing my application, class, method, domain, etc...

In response to your scenario I agree with what S.Lott implied is that what you are needing is a suite of Unit tests to test specific behaviors in your application.

Solution 4:

TDDing a simple CRUD application is in my opinion kind of like practicing scales on a guitar- you may think that it's boring and tedious only to discover how much your playing improves. In development terms - you would be likely to write code that's less coupled - more testable. Additionally you're more likely to see things from the code consumer's perspective - you'll actually be using it. This can have a lot of interesting side effects like more intuitive API's, better segregation of concerns etc. Granted there are scaffold generators that can do basic CRUD for you and they do have a place especially for prototyping, however they are usually tied to a framework of sorts. Why not focus on the core domain first, deferring the Framework / UI / Database decisions until you have a better idea of the core functionality needed - TDD can help you do that as well. In your example: Do you want messages to be a queue or a hierarchical tree etc? Do you want them to be loaded in real time? What about sorting / searching? do you need to support JSON or just html? it's much easier to see these kinds of questions with BDD / TDD. If you're doing TDD you may be able to test your core logic without even using a framework (and waiting a minute for it to load / run)

Solution 5:

Skip it. All will be just fine. I'm sure you have a deadline to meet. (/sarcasm)

Next month, we can go back and optimize the queries based on user feedback. And break things that we didn't know we weren't supposed to break.

If you think the project will last 2 weeks and then never be reopened, automated testing probably is a waste of time. Otherwise, if you have a vested interest in "owning" this code for a few months, and its active, build some tests. Use your judgement as to where the most risk is. Worse, if you plan on being with the company for a few years, and have other teammates who take turns whacking on various pieces of a system, and it may be your turn again a year from now, build some tests.

Don't over do it, but do "stick a few pins in it", so that if things start to "move around", you have some alarms to call attention to things.

Most of my testing has been JUnit or batch "diff" type tests, and a rudimentaryy screen scraper type tool I wrote a few years ago (scripting some regex + wget/curl type stuff). I hear Selenium is supposed to be a good tool for web app UI testing, but have not tried it. Anybody have available tools for local GUI apps???