Page 2 of 2

Re: BDD/TDD for Applications

Posted: Tue Jul 15, 2008 7:03 am
by Jenk
The case in point is that you are testing that the target object sends the SQL to the peered object (in this case the data accessor) you are not testing the data accessor at this time, as it should have been tested elsewhere. PDO for example.. it is not necessary to test the functionality of PDO with every application.. you only need to assert that the application sends the expected strings to prepare()/exec()/etc.

Re: BDD/TDD for Applications

Posted: Thu Dec 04, 2008 8:34 am
by inghamn
I think we've had this discussion before:
viewtopic.php?f=39&t=88866

My applications' models are active record style, generated code. By active record, I mean to say that I have a class that represents one row from a table. In that class is both database code (sql for save, load, delete) and any business logic needed. The code is generated from looking at the database, but then gets modified from there. As the database design changes, I needed a way to make sure my models still functioned correctly (make sure the model gets saved and restored with all the data the same.) These models are the ORM for my applications. Testing the ORM really has to query the database to make sure that the schema the models are written against is, in fact, the schema that's in the database.

Since then, I've noticed something new...98% of the code in all of my tests are in the database tests. I only have a very small number of tests in the unit test side of things ( and this is with very good code coverage on the mdels) It's starting to seem like web applications are simple enough there's really not any business logic to test. You mileage might vary, of course, but most all of the applications I write are pretty basic interfaces to let users enter and save data.

I have not changed to a full, external ORM stack, like Propel or Doctrine yet. Mostly because what I'm seeing with the applications I'm writing, there's not enough business logic to necessitate it.