Applying TDD when the application is 100% CRUD

Question

I routinely run into this problem, and I\'m not sure how to get past this hurdle. I really want to start learning and applying Test-Driven-Development (or BDD, or whatever) but

Answer 1

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???

Answer 2

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)

Answer 3

I am working on a CRUD application now. What I am doing at this point is writing unit tests on my Repository objects and test that the CRUD features are working as they should. I have found that this has inherently unit tested the actual database code as well. We have found quite a few bugs in the database code this way. So I would suggest you push ahead and keep going with unit tests. I know applying TDD on CRUD apps is not as glamorous as things you might read about in blogs or magazines, but it is serving its purpose and you will be that much better when you work on a more complex application.

Answer 4

I see what you are saying, but eventually your models will become sufficiently advanced that they will require (or be greatly augmented by) automated testing. If not, what you are essentially developing is a spreadsheet which somebody has already developed for you.

Since you mentioned Rails, I would say doing a standard create/read/update/delete test is a good idea for each property, especially because your test should note permissions (this is huge I think). This also ensures that your migrations work as you expected them to.

Answer 5

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.

Answer 6

"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?