I''ve just finished working through the testing section of the rails beta book from pragmatic programmers, this section alone was worth the price I think. I''m very interested to know what sort of workflow people use in test first development, and what would be considered the best practice. Would you, for example, write tests for a model, then implement the model, then move on the the next model followed by the controllers etc.? Or write tests for the whole application first? David North _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
I definatelly wouldn''t write tests for the whole application first. Requirements change on the fly, and if you test everything first, they you don''t have that flexibility. If you''re looking to do test driven development, then I''d suggest applying the rule of "not writing any model or controller code without first having a failing test, and then only writing the code needed to make it pass". Then, try and make your app do something. Typically you can''t _do_ anything without some controller code, so I''d first write a controller test (although initially, this might take the form of scaffolding, which generates it''s own tests). The controller test might ensure that the controller does something to a model, and then displays something. Normally, I would try and write this test against a mock version of the model. However, that doesn''t seem to be the rails testing philosophy (because it would probably require dependency injection). I guess that''s just me leaning towards wanting to unit test my controllers, which may not be necessary. Instead, rails pushes you towards what it calls functional tests for controllers. This tests the whole system from the controller through the model to the database. However, a testing database is used, with data loaded from a fixture. So, I would write one of these functional tests first, but I might find that I''m unable to get it working without adding more functionality to a model. To do this, I would first create a test for the model. When doing test driven development, people often find that they pick an initial test which is fairly large in scope, and making it pass requires the creation of a smaller (or several smaller) test. Some people like to comment out the original test while working on this newly descovered dependency, others feel that it''s ok to have two failing tests at once. So, to get back towards answering your question, I''m finding (still being fairly new to rails), that I''m driving the tests with a desire for new functionality in the controller, and this is then forcing me to add new functionality to models. My testing cycle thus looks something like this. for each task Controller Test Model Test Model Test Passing Model Test Model Test Passing Controller Test Passing I hope that helps. I''m keen to talk to more people about their TDD styles with rails, as I''m finding the documentation (even the new beta book) to be somewhat lacking in this area. Craig On Tue, 31 May 2005 7:29 pm, David North wrote:> I''m very interested to know what sort of workflow people use in test first > development, and what would be considered the best practice. Would you, for > example, write tests for a model, then implement the model, then move on > the the next model followed by the controllers etc.? Or write tests for the > whole application first?-- Craig Ambrose Web Elements http://www.portallus.com/people/craigambrose/
On 31/05/2005, at 7:29 PM, David North wrote:> I''ve just finished working through the testing section of the rails > beta book from pragmatic programmers, this section alone was worth the > price I think. > > I''m very interested to know what sort of workflow people use in test > first development, and what would be considered the best practice. > Would you, for example, write tests for a model, then implement the > model, then move on the the next model followed by the controllers > etc.? Or write tests for the whole application first?Unless you have a rock solid view of what you are developing, I recommend doing the view in vanilla xhtml first, then moving on to controller+model tests, bringing each bit of UI "alive" and refactoring as you go. - tim lucas
A big problem I''m seeing is that "rake test_units" takes an age to actually execute my tests, even on a fairly decent dev box. TDD relies on instant feedback of course! Are other people seeing their tests run within a couple of seconds? Or is everyone seeing their tests take longer than 10 seconds (my boredom threshold)? Is this something to do with the windows impl of ruby? I''m a version down on the one-click installer... Fairly frustrated that I''m not finding TDD very practical at the moment!> -----Original Message----- > From: Craig Ambrose [mailto:craiga-aW5oDkNkUadaA94nB1n4cRCuuivNXqWP@public.gmane.org] > Sent: 31 May 2005 10:49 > To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > Subject: Re: [Rails] Workflow for test first development > > > I definatelly wouldn''t write tests for the whole application first. > Requirements change on the fly, and if you test everything first, they you > don''t have that flexibility. > > If you''re looking to do test driven development, then I''d suggest applying > the > rule of "not writing any model or controller code without first having a > failing test, and then only writing the code needed to make it pass". > Then, > try and make your app do something. Typically you can''t _do_ anything > without > some controller code, so I''d first write a controller test (although > initially, this might take the form of scaffolding, which generates it''s > own > tests). The controller test might ensure that the controller does > something > to a model, and then displays something. > > Normally, I would try and write this test against a mock version of the > model. > However, that doesn''t seem to be the rails testing philosophy (because it > would probably require dependency injection). I guess that''s just me > leaning > towards wanting to unit test my controllers, which may not be necessary. > Instead, rails pushes you towards what it calls functional tests for > controllers. This tests the whole system from the controller through the > model to the database. However, a testing database is used, with data > loaded > from a fixture. > > So, I would write one of these functional tests first, but I might find > that > I''m unable to get it working without adding more functionality to a model. > To > do this, I would first create a test for the model. > > When doing test driven development, people often find that they pick an > initial test which is fairly large in scope, and making it pass requires > the > creation of a smaller (or several smaller) test. Some people like to > comment > out the original test while working on this newly descovered dependency, > others feel that it''s ok to have two failing tests at once. > > So, to get back towards answering your question, I''m finding (still being > fairly new to rails), that I''m driving the tests with a desire for new > functionality in the controller, and this is then forcing me to add new > functionality to models. My testing cycle thus looks something like this. > > for each task > Controller Test > Model Test > Model Test Passing > Model Test > Model Test Passing > Controller Test Passing > > I hope that helps. I''m keen to talk to more people about their TDD styles > with > rails, as I''m finding the documentation (even the new beta book) to be > somewhat lacking in this area. > > Craig > > On Tue, 31 May 2005 7:29 pm, David North wrote: > > I''m very interested to know what sort of workflow people use in test > first > > development, and what would be considered the best practice. Would you, > for > > example, write tests for a model, then implement the model, then move on > > the the next model followed by the controllers etc.? Or write tests for > the > > whole application first? > > -- > Craig Ambrose > Web Elements > http://www.portallus.com/people/craigambrose/ > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On 31/05/2005, at 8:38 PM, Steve Meyfroidt wrote:> A big problem I''m seeing is that "rake test_units" takes an age to > actually > execute my tests, even on a fairly decent dev box. TDD relies on > instant > feedback of course! > > Are other people seeing their tests run within a couple of seconds? Or > is > everyone seeing their tests take longer than 10 seconds (my boredom > threshold)?The ''recent'' rake task will run tests modified in the past 10 minutes... but yes... testing is sloow - tim lucas
On 31.5.2005, at 14:13, Tim Lucas wrote:> On 31/05/2005, at 8:38 PM, Steve Meyfroidt wrote: >> Are other people seeing their tests run within a couple of seconds? >> Or is >> everyone seeing their tests take longer than 10 seconds (my boredom >> threshold)? > > The ''recent'' rake task will run tests modified in the past 10 > minutes... > > but yes... testing is sloowHave you read the thread about using sqlite + ramdisks for the test database? I haven''t done that myself but it is said to give a major boost in test performance. You might want to search the list archives for more information. //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Tue, 31 May 2005 9:13 pm, Tim Lucas wrote:> but yes... testing is sloowUnit testing doesn''t have to be slow. Rails seems to push towards testing models with a real database, which I''ve never done before. Surely if it''s a real ''unit'' test there should be nothing being executed but the class under test? Fixtures and so forth are great, but that seems to be more for integration or acceptance testing. Now, I''m not trying to winge about the way that rails does things. On the whole, I think it''s great. But, perhaps it''s worth bearing in mind that model tests don''t _have_ to use the database. I need to do a bit more of this before I can say anything very intelligent on the subject, but I''ve certainly managed in other languages. If I come up with any convenient practices in this area, I''ll write up something on the subject. Craig -- Craig Ambrose Web Elements http://www.portallus.com/people/craigambrose/
* Craig Ambrose <craiga-aW5oDkNkUadaA94nB1n4cRCuuivNXqWP@public.gmane.org> [0529 14:29]:> Now, I''m not trying to winge about the way that rails does things. On the > whole, I think it''s great. But, perhaps it''s worth bearing in mind that model > tests don''t _have_ to use the database.But surely ActiveRecord models do? Half an AR model is in in the db,isn''t it? -- ''Good news, everyone! I''ve taught the toaster to feel love!'' -- Prof. Farnsworth Rasputin :: Jack of All Trades - Master of Nuns
The tests themselves aren''t in the db; what makes it slow (at least partially) is that rake clones the database structure every time you test. So, it drops the test db, grabs the schema from devel, recreates the test db from that schema, then loads fixtures ... the "recent" tasks may not do this; not sure. On 5/31/05, Dick Davies <rasputnik-ogHSZ3ARDZIOXkKaSkYkkl6hYfS7NtTn@public.gmane.org> wrote:> * Craig Ambrose <craiga-aW5oDkNkUadaA94nB1n4cRCuuivNXqWP@public.gmane.org> [0529 14:29]: > > Now, I''m not trying to winge about the way that rails does things. On the > > whole, I think it''s great. But, perhaps it''s worth bearing in mind that model > > tests don''t _have_ to use the database. > > But surely ActiveRecord models do? Half an AR model is in in the db,isn''t it? > > -- > ''Good news, everyone! I''ve taught the toaster to feel love!'' > -- Prof. Farnsworth > Rasputin :: Jack of All Trades - Master of Nuns > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
> > tests don''t _have_ to use the database. > > But surely ActiveRecord models do? Half an AR model is in in the db,isn''t > it?I think that''s the point. I seem to have ended up with a significant part of my "logic" expressed in SQL. (I''m not complaining about that because the amount of code I have is ridiculously small... for an ex-J2EE guy.) I suspect that doing "real" unit tests with mocks would be self-defeating, and may end up in the full implementation of a mock SQL processor... probably no fun. I''ve noticed that a fair proportion of time is spent before ever hitting the first test. At that point in the run I''m not convinced there''s any significant DB access, yet the CPU is maxxed for a long time. Are there some optimizations to be made in preparing the rails environment? What does it do in there? Is it "requiring" lots of files in advance of any action? Steve
Michael Campbell <michael.campbell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:> So, it drops the test db, grabs the schema from devel, recreates the > test db from that schema, then loads fixtures ...I''m not exactly sure what all it does, but I _know_ ''rake test_units'' doesn''t pull the devel db scheme. I always have to clone_structure_to_test when I make db changes. -- doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org
On Tue, 31 May 2005 11:59 pm, Michael Campbell wrote:> > > Now, I''m not trying to winge about the way that rails does things. On > > > the whole, I think it''s great. But, perhaps it''s worth bearing in mind > > > that model tests don''t _have_ to use the database. > > > > But surely ActiveRecord models do? Half an AR model is in in the db,isn''t > > it?Absolutelly not. ActiveRecord models are concrete classes which encapsulate both data and business logic. They do inherit database functionality from active record, but it''s quite possible to use one without calling fetch or save. For example, consider an ActiveRecord model class called Customer: def test_expired_is_true_if_expiry_date_has_passed customer = Customer.new customer.date = Time.now + 1 assert_equal(true, customer.expired) end A very simple little test which did not involve accessing the database. Admitedly I''m only testing an overblown accessor. This function encapsulates an expression on the customer''s data, but doesn''t _do_ anything. For methods which do things, it''s more complex. Imagine a method on Customer called "add_product", which takes a Product model, and stores it in the customer''s internal list, and "products" which returns a collection of existing products. The lines below using mock objects are psuedo-code, and depend on the mock library being used. def_test_products_returns_added_product customer = Customer.new product = Mock(Product ).new customer.addProduct(product) assert_equal(product, customer.products[0]) end def test_add_product_sets_products_customer customer = Customer.new product = Mock(Product).new product.expectOnce(:customer=, customer) product.expectOnce(:save) customer.addProduct(product) product.verify end The code in the second test where expectations are set is based more upon a mock library from PHP, because I don''t really understand the ruby mock libraries yet (and they don''t seem to handle expectations very well), but you get the idea. Anyway, those examples may seem a little contrived. If anyone has an example of a test for a model object which is simple enough to quickly psuedocode, but they feel absolutelly must use the database (and presumably a fixture), then I''d love to see it. Craig -- Craig Ambrose Web Elements http://www.portallus.com/people/craigambrose/
On Tuesday 31 May 2005 09:29 am, Craig Ambrose wrote:> On Tue, 31 May 2005 9:13 pm, Tim Lucas wrote: > > but yes... testing is sloow > > Unit testing doesn''t have to be slow. Rails seems to push towards testing > models with a real database, which I''ve never done before. Surely if it''s a > real ''unit'' test there should be nothing being executed but the class under > test? Fixtures and so forth are great, but that seems to be more for > integration or acceptance testing.I''m in complete agreement with you on this, Craig. I''ve been finding Rails difficult because it is database bound, and there is little support for unit-testing views and controllers (only larger, "functional tests"). I''m working my first app, and I''m trying to develop better support for these areas as I go.> Now, I''m not trying to winge about the way that rails does things. On the > whole, I think it''s great. But, perhaps it''s worth bearing in mind that > model tests don''t _have_ to use the database.Don''t they in Rails? Doesn''t rails dynamically define a number of methods for various properties and associations? How can that model (based on ActiveRecord::Base) be used without the database?> I need to do a bit more of > this before I can say anything very intelligent on the subject, but I''ve > certainly managed in other languages. If I come up with any convenient > practices in this area, I''ll write up something on the subject.> > Craig
On Tuesday 31 May 2005 07:34 pm, Craig Ambrose wrote:> On Tue, 31 May 2005 11:59 pm, Michael Campbell wrote: > > > > Now, I''m not trying to winge about the way that rails does things. On > > > > the whole, I think it''s great. But, perhaps it''s worth bearing in > > > > mind that model tests don''t _have_ to use the database. > > > > > > But surely ActiveRecord models do? Half an AR model is in in the > > > db,isn''t it? > > Absolutelly not. ActiveRecord models are concrete classes which encapsulate > both data and business logic. They do inherit database functionality from > active record, but it''s quite possible to use one without calling fetch or > save. > > For example, consider an ActiveRecord model class called Customer: > > def test_expired_is_true_if_expiry_date_has_passed > customer = Customer.new > customer.date = Time.now + 1 > assert_equal(true, customer.expired) > end > > A very simple little test which did not involve accessing the database. > Admitedly I''m only testing an overblown accessor. This function > encapsulates an expression on the customer''s data, but doesn''t _do_ > anything.Is ''date'' a column in the customers table of the database? Does this test work without a database running?
Yep, date is a column in the customers table, and thus an instance variable in
the Customer class. My code also presumes that a setter ("date=") has
been
created for Customer. In hindsite, it was poorly named, and should probably
have been "expiry_date", but you get the idea.
Does this test work without the database running? Not exactly.
It doesn''t rely upon a fixture, but it does use the database schema.
So, I
believe that Active Record needs the testing database has to exist, and have
the correct structure, but it doesn''t need to have any data. However,
it
seems to me that even this isn''t necessary, as the code for customer
would be
exactly the same even if it wasn''t inherited from ActiveRecord.
So my question for the floor is:
- When does active record check the database schema? Does it do it on
construction of the object, during some static initialisation phase for the
class (sorry, showing my C++ background here), or does it do it the first
time a call is made to "find" or "save".
Based on what little I know about how this stuff works, I believe that it
should be possible to execute model code the doesn''t rely on the
database,
without even needing a database server, without sacrificing any of the
functionality of ActiveRecord or introducing any configuration files or
wotnot. In fact, this may already be possible and I just haven''t
spotted yet.
Craig
On Wed, 1 Jun 2005 10:31 am, David Corbin wrote:> > def test_expired_is_true_if_expiry_date_has_passed
> > customer = Customer.new
> > customer.date = Time.now + 1
> > assert_equal(true, customer.expired)
> > end
>
> Is ''date'' a column in the customers table of the
database? Does this test
> work without a database running?
--
Craig Ambrose
Web Elements
http://www.portallus.com/people/craigambrose/
[snip]> - When does active record check the database schema? Does it do it on > construction of the object, during some static initialisation phase for the > class (sorry, showing my C++ background here), or does it do it the first > time a call is made to "find" or "save".For all intents and purposes, the connection happens during the ''static initialisation phase''. The connection will also be queried on ''new'' as the defaults have to be applied. So you basically can''t get a reference to a model instance without hitting the database at least once.> Based on what little I know about how this stuff works, I believe that it > should be possible to execute model code the doesn''t rely on the database, > without even needing a database server, without sacrificing any of the > functionality of ActiveRecord or introducing any configuration files or > wotnot. In fact, this may already be possible and I just haven''t spotted yet.I find it hard to see what your tests will do? Without the DB connection there are no attributes on your models. take the following class User < AR::base def owes_money? balance < 0 end end You can''t test owes_money without a balance, and you can''t have a balance without a db. I''m a ''mock skeptic'', so I''ll leave any issues there to others.> Craig > > On Wed, 1 Jun 2005 10:31 am, David Corbin wrote: > > > def test_expired_is_true_if_expiry_date_has_passed > > > customer = Customer.new > > > customer.date = Time.now + 1 > > > assert_equal(true, customer.expired) > > > end > > > > Is ''date'' a column in the customers table of the database? Does this test > > work without a database running? > > -- > Craig Ambrose > Web Elements > http://www.portallus.com/people/craigambrose/ > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Cheers Koz
> For all intents and purposes, the connection happens during the > ''static initialisation phase''. The connection will also be queried on > ''new'' as the defaults have to be applied. So you basically can''t get > a reference to a model instance without hitting the database at least > once.Ah, that''s what I feared. :) I''m wish that wasn''t the case. I''m sure that it doesn''t have to be.> I find it hard to see what your tests will do? Without the DB > connection there are no attributes on your models. take the following > > class User < AR::base > def owes_money? > balance < 0 > end > end > > You can''t test owes_money without a balance, and you can''t have a > balance without a db. I''m a ''mock skeptic'', so I''ll leave any issues > there to others.This problem has nothing to do with mocks, since there are no objects being uses except for the user. And yes, you can have a balance without a db, you just supply one in the test. In fact, I believe that this makes the test much more readable than having to check a fixture file to see what values your testing against. If the values that your initialising it with become repeated in multiple tests, you move them to the set_up function. Here''s are tests for your owes money function: def test owes_money_is_true_if_balance_is_negative user = User.new user.balance = -1 assert_equal(true, owes_money) end def test owes_money_is_false_if_balance_is_zero user = User.new user.balance = 0 assert_equal(false, owes_money) end I would probably also test for balance = 1. You''ll notice that my tests require the introduction of a public setter method for balance. However, I think that this is justified by the design. I would just add it to the class. If you don''t agree, then no probs, you just extend the class in the test file to add the setter method. And for any skeptics in the audience, it''s worth noting that I''m not saying that you _should_ unit test, merely that if you do wish to unit test, this is _a_ valid way of doing it. Also, I''m not suggesting any new or original techniques. Not being a master at this myself, I''m basically following stock TDD as suggested by the extreme programming folks (ie; Beck, Kent "Test-Driven Development by Example"). Craig -- Craig Ambrose Web Elements http://www.portallus.com/people/craigambrose/
On 6/1/05, Craig Ambrose <craiga-aW5oDkNkUadaA94nB1n4cRCuuivNXqWP@public.gmane.org> wrote:> > > For all intents and purposes, the connection happens during the > > ''static initialisation phase''. The connection will also be queried on > > ''new'' as the defaults have to be applied. So you basically can''t get > > a reference to a model instance without hitting the database at least > > once. > > Ah, that''s what I feared. :) I''m wish that wasn''t the case. I''m sure that it > doesn''t have to be. > > > I find it hard to see what your tests will do? Without the DB > > connection there are no attributes on your models. take the following > > > > class User < AR::base > > def owes_money? > > balance < 0 > > end > > end > > > > You can''t test owes_money without a balance, and you can''t have a > > balance without a db. I''m a ''mock skeptic'', so I''ll leave any issues > > there to others. > > This problem has nothing to do with mocks, since there are no objects being > uses except for the user. And yes, you can have a balance without a db, you > just supply one in the test.Except that without the DB, there''s no balance= method. This is where it the ''db independent unit tests'' fall down. -- Cheers Koz
On Tuesday 31 May 2005 10:49 pm, Craig Ambrose wrote:> > class User < AR::base > > def owes_money? > > balance < 0 > > end > > end > > > > You can''t test owes_money without a balance, and you can''t have a > > balance without a db.> As mentioned in another follow up, the basic problem is that the balance "property" and related methods don''t exist in the User object.until it talks to the database (through an adapter). Now, personally i''m not really too keen on defining my object model by writing SQL. It just seems wrong. I''m of mind that we should be able to write an adapter for the "development-mode" that would work by accessing ruby code (probabaly the model object) and the "SQL" would be written in Ruby. I just haven''t gotten to it yet. David
* David Corbin <dcorbin-wmGZ+vDKSyrZJqsBc5GL+g@public.gmane.org> [0606 10:06]:> Now, personally i''m not really too keen on defining my object model by writing > SQL. It just seems wrong. I''m of mind that we should be able to write an > adapter for the "development-mode" that would work by accessing ruby code > (probabaly the model object) and the "SQL" would be written in Ruby. I just > haven''t gotten to it yet.My gut reaction on first using AR was to agree with you, but since then I''ve got used to it. All the db really does in my limited rails projects is store attributes (and enforces a bit of sanity in a belt and braces manner). I assumed I''d need to mock out a lot of db functionality too, as all my TDD references say I''ll need to, but I havent'' found that necessary yet. An OOP wrapper to SQL ends up looking like EJB - if you dislike SQL that much its probably worth using some other backend :) I believe Og (part of the Nitro project) takes the ''ruby code defines the db layout'' approach, have a look at that if you want to compare the two approaches. -- ''Oh how awful. Did he at least die peacefully? ....To shreds you say, tsk tsk tsk. Well, how''s his wife holding up? ....To shreds, you say...'' -- Prof. Farnsworth Rasputin :: Jack of All Trades - Master of Nuns
On Thursday 02 June 2005 03:08 am, Dick Davies wrote:> My gut reaction on first using AR was to agree with you, but since then > I''ve got used to it. All the db really does in my limited rails projects is > store attributes (and enforces a bit of sanity in a belt and braces > manner).AND define the actual properties of the model (i.e., not just store them).> > I assumed I''d need to mock out a lot of db functionality too, as all my TDD > references say I''ll need to, but I havent'' found that necessary yet.I''ve worked on two long Java projects (15+ months, ~8+ developers). One had 800 UTs that took about 2 minutes to run (they weren''t well focused UTs, and they used an in-memory SQL database), and the other has 3500+ UTs that take about 35 seconds to run (reasonably focused, no database). I dread the thought of how long those 3500 would take with a database requirement. I agree that it''s probably not *necessary*, only painful on a large project. My rails projects will probably not get that large in the next couple of years, so I may not do it.> > An OOP wrapper to SQL ends up looking like EJB - if you dislike SQL that > much its probably worth using some other backend :)How does it look end up looking like EJB? I certainly don''t want that :) David
On Thursday 02 June 2005 13:04, David Corbin wrote:> AND define the actual properties of the model (i.e., not just store them). > > > I assumed I''d need to mock out a lot of db functionality too, as all my > > TDD references say I''ll need to, but I havent'' found that necessary yet.Tell me. What stops you from defining properties of the model via for example a yaml file? Loading a files once per testsuite is quite cheap operation. this yaml can be generated from db schema automagically. What else? -- Best regards, Stanislav Karchebny Skype name: berkus Get skype for free from www.skype.com _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Thursday 02 June 2005 06:43 am, Stanislav Karchebny wrote:> On Thursday 02 June 2005 13:04, David Corbin wrote: > > AND define the actual properties of the model (i.e., not just store > > them). > > > > > I assumed I''d need to mock out a lot of db functionality too, as all my > > > TDD references say I''ll need to, but I havent'' found that necessary > > > yet. > > Tell me. > What stops you from defining properties of the model via for example a yaml > file? Loading a files once per testsuite is quite cheap operation. this > yaml can be generated from db schema automagically. What else?First, to be clear, I mean declare what the properities of the object are, not their value. I go look at the Circle model object, but no where in it is ''center'', or ''radius'', yet these are integral to the definition of a Circle. Now, I''m not 100% clear on all aspects of the yaml fixtures, but even if you could declare what the properties are in a yaml file, it still suffers the same problem The definition of Circle is split into two locations. David
On Thursday 02 June 2005 14:23, David Corbin wrote:> > What stops you from defining properties of the model via for example a > > yaml file? Loading a files once per testsuite is quite cheap operation. > > this yaml can be generated from db schema automagically. What else? > > First, to be clear, I mean declare what the properities of the object are, > not their value. I go look at the Circle model object, but no where in it > is ''center'', or ''radius'', yet these are integral to the definition of a > Circle.Yes, you can declare those attributes from whatever source you want, pretty much like AR does it by reflecting the db. I believe this is a holy war akin emacs vs vi or gnome vs kde, same thing is class-defines-db vs db-defines-class argument.> Now, I''m not 100% clear on all aspects of the yaml fixtures, but even if > you could declare what the properties are in a yaml file, it still suffers > the same problem The definition of Circle is split into two locations.So, you are proposing absolute absence of model.rb file and totally on-the-fly generation of it from the db? :))) (this is possible of course) -- Best regards, Stanislav Karchebny Skype name: berkus Get skype for free from www.skype.com _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Thursday 02 June 2005 07:33 am, Stanislav Karchebny wrote:> > First, to be clear, I mean declare what the properities of the object > > are, not their value. I go look at the Circle model object, but no where > > in it is ''center'', or ''radius'', yet these are integral to the definition > > of a Circle. > > Yes, you can declare those attributes from whatever source you want, pretty > much like AR does it by reflecting the db.And I want to define those attributes in Ruby, but otherwise using AR ''as is'' (in the ideal world).> > I believe this is a holy war akin emacs vs vi or gnome vs kde, same thing > is class-defines-db vs db-defines-class argument.It probably is.> > > Now, I''m not 100% clear on all aspects of the yaml fixtures, but even if > > you could declare what the properties are in a yaml file, it still > > suffers the same problem The definition of Circle is split into two > > locations. assert_element_exists(id("tile(0,0)"), :td)> > So, you are proposing absolute absence of model.rb file and totally > on-the-fly generation of it from the db? :))) > (this is possible of course)No. Just the opposite. I want it all in the model .rb.
On Thursday 02 June 2005 14:46, David Corbin wrote:> And I want to define those attributes in Ruby, but otherwise using AR ''as > is'' (in the ideal world).You see, Rails is not supposed to work like this. If you define you attributes in model, it might probably work (AR could be just giving warnings when redefining accessors probably?), but eventually your model file and db will go out of sync (this is what rails is trying to avoid!) You could probably hack together an implementation that uses nitro/og to propagate properties of a model onto the db schema plus AR''s validations module (i guess there''s nothing else you want from AR?). You can of course go hibernate route and define both model and db schema in an XML file but i can see DHH frowning upon you from here already.> > So, you are proposing absolute absence of model.rb file and totally > > on-the-fly generation of it from the db? :))) > > (this is possible of course) > > No. Just the opposite. I want it all in the model .rb.It was a joke. -- Best regards, Stanislav Karchebny Skype name: berkus Get skype for free from www.skype.com _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Thursday 02 June 2005 07:56 am, Stanislav Karchebny wrote:> On Thursday 02 June 2005 14:46, David Corbin wrote: > > And I want to define those attributes in Ruby, but otherwise using AR ''as > > is'' (in the ideal world). > > You see, Rails is not supposed to work like this. If you define you > attributes in model, it might probably work (AR could be just giving > warnings when redefining accessors probably?), but eventually your model > file and db will go out of sync (this is what rails is trying to avoid!)I want to generate the DB from the Ruby model. If I did that, they wouldn''t get out of sync any more than they do now.> > You could probably hack together an implementation that uses nitro/og to > propagate properties of a model onto the db schema plus AR''s validations > module (i guess there''s nothing else you want from AR?). >Well, my AR experience is very limited. Mostly my thought was that it ought to be able to modify/extended it so that you can generate the DB from it, and just use all the rest of it "as is". I just have gotten around to trying it.> You can of course go hibernate route and define both model and db schema in > an XML file but i can see DHH frowning upon you from here already.I don''t want that - no XML, and don''t what DHH frowning :)
On Friday 03 June 2005 01:48, you wrote:> > You see, Rails is not supposed to work like this. If you define you > > attributes in model, it might probably work (AR could be just giving > > warnings when redefining accessors probably?), but eventually your model > > file and db will go out of sync (this is what rails is trying to avoid!) > > I want to generate the DB from the Ruby model. If I did that, they > wouldn''t get out of sync any more than they do now.I''m sure this is perfectly doable, especially once AR is cleaned up of helpers that are twined with it atm (validators?). Then we could have ActiveRecord and PassiveRecord (*shrug*), which communicate just fine with the rest of rails. This will bring us the best of two worlds (and if we manage to use _both_ together it will be mind blowing, tho a little contrived to my taste). I think this is a perfect project in time and effort estimates for Google''s Summer of Code, hey any takers? -- Best regards, Stanislav Karchebny Skype name: berkus Get skype for free from www.skype.com _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
* Stanislav Karchebny <berkus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [0647 11:47]:> On Thursday 02 June 2005 13:04, David Corbin wrote: > > > AND define the actual properties of the model (i.e., not just store them). > > > > > I assumed I''d need to mock out a lot of db functionality too, as all my > > > TDD references say I''ll need to, but I havent'' found that necessary yet. > > > Tell me. > What stops you from defining properties of the model via for example a yaml > file? Loading a files once per testsuite is quite cheap operation. this yaml > can be generated from db schema automagically. What else?Nothing would stop you, but you''d have to write extra code to handle all the habtm etc functionality that you get for nothing with AR backed by a database - and since you have a db anyway, what''s the point? Is yaml really that much slower than db with fixtures? -- ''When the door hits you in the ass on the way out, clean off the smudge your ass leaves, please'' -- Alien loves Predator Rasputin :: Jack of All Trades - Master of Nuns _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Wednesday 08 June 2005 23:50, Dick Davies wrote:> > What stops you from defining properties of the model via for example a > > yaml file? Loading a files once per testsuite is quite cheap operation. > > this yaml can be generated from db schema automagically. What else? > > Nothing would stop you, but you''d have to write extra code to handle all > the habtm etc functionality that you get for nothing with AR backed by a > database - and since you have a db anyway, what''s the point? Is yaml really > that much slower than db with fixtures?Didn''t get the last sentence. Isn''t it the other way around? -- Best regards, Stanislav Karchebny Skype name: berkus Get skype for free from www.skype.com _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Wed, 1 Jun 2005, Craig Ambrose wrote:> Based on what little I know about how this stuff works, I believe that it > should be possible to execute model code the doesn''t rely on the database, > without even needing a database server, without sacrificing any of the > functionality of ActiveRecord or introducing any configuration files or > wotnot. In fact, this may already be possible and I just haven''t spotted yet.I wouldn''t get too excited about a bit of database access. Just trim it down and you''ll be fine. For example, in my current ruby-web-db-etc. project, my ruby unit tests run about 150 tests with 600 assertions in about 2.25 seconds. Some of these hit the database, but not a lot of them. There are a couple of tricks here: 1. Do testing against the database, but don''t do it where you don''t have to. I usually test my database access classes directly, but frequently use mock objects instead of them when testing other parts of the system. 2. Don''t reload the db if you don''t have to. That will save a lot of setup time. All tests that run aginst the DB run in a transaction that''s rolled back at the end, so I know that I''m starting with the same database every time. If you look at the web functional tests (130 tests and about 1300 assertions) you see what happens when you start doing end-to-end testing with everything touching the DB: the tests themselves take around 45 seconds to run, and there''s another ten seconds or more of setup time to load up the DB and start up the web servers. cjs -- Curt Sampson <cjs-gHs2Wiolu3leoWH0uzbU5w@public.gmane.org> +81 90 7737 2974 http://www.NetBSD.org Make up enjoying your city life...produced by BIC CAMERA