tag:blogger.com,1999:blog-3718956085911858962.post3456472239881833496..comments2023-12-27T14:48:02.113+05:30Comments on Electric Sheep Blog: Non-rails unit tests don't hit the db but Rails unit tests doAnonymoushttp://www.blogger.com/profile/11938300811286150164noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-3718956085911858962.post-71582383984625102872007-08-24T12:02:00.000+05:302007-08-24T12:02:00.000+05:30bluefish,One way of figuring out whether you are o...bluefish,<BR/>One way of figuring out whether you are on the right path is by answering the question, "Which unit are you testing with your unit tests?"<BR/>In the case of Rails, you end up implicitly testing much of ActiveRecord as well, something that is not your responsibility to test. This also means that you are no longer testing 'units' of code, but rather a combination of your code and a slice of AR. Changes to AR can now affect the outcome of your tests.<BR/><BR/>aslak,<BR/>Dan Manges has done a much better job - see <A HREF="http://www.dcmanges.com/blog/rails-unit-record-test-without-the-database" REL="nofollow">Rails: UnitRecord - Test without the Database</A>Anonymoushttps://www.blogger.com/profile/11938300811286150164noreply@blogger.comtag:blogger.com,1999:blog-3718956085911858962.post-458916403936676672007-08-23T18:33:00.000+05:302007-08-23T18:33:00.000+05:30I sort of agree i think business logic code should...I sort of agree i think business logic code should go no place near the DB but what about data tiers and data dictionary do you not have boundary tests for these ? <BR/><BR/>I regularly write TTD driven data suits with there own database tear down and setup scripts.BlueFishhttps://www.blogger.com/profile/04570965259832525695noreply@blogger.comtag:blogger.com,1999:blog-3718956085911858962.post-65924416109732513202007-07-02T11:05:00.000+05:302007-07-02T11:05:00.000+05:30I guess my thinking is coloured by the kind of wor...I guess my thinking is coloured by the kind of work we do. On most client projects, we end up having little or no control over the db schema (you'd know more about this than I, Aslak :-D). Given this constraint, it seems wiser to ensure that the schema was abstracted away from the model so that schema changes didn't directly affect them.<BR/>Have I missed something?Anonymoushttps://www.blogger.com/profile/11938300811286150164noreply@blogger.comtag:blogger.com,1999:blog-3718956085911858962.post-46391147109258325602007-07-02T06:47:00.000+05:302007-07-02T06:47:00.000+05:30RSpec, with its support for one-layer testing of R...RSpec, with its support for one-layer testing of Rails code makes it easier to test controllers, views and helpers independently of models (and the database).<BR/><BR/>I agree with you in principle that it's healthy to try and keep the (domain) model agnostic of the database - especially because it speeds up testing.<BR/><BR/>You said one thing that made me curious: <BR/><BR/>"This is because you should be able to create and use models independently of your database - otherwise your code is implicitly tied to your db schema, something you want to avoid."<BR/><BR/>I would be interested in hearing why you think this dependency on a database schema should be avoided.Aslak Hellesøyhttps://www.blogger.com/profile/05425581666293755697noreply@blogger.com