rspec users - Sep 2012 - How can I create a active-record model w/o depending on the database?

I have a class that takes a class that inherits from activerecord as a
parameter, e.g.:

class SomeModel < ActiveRecord::Base
end

class MyClass
  attr_accessor :model
  def initialize(model)
    @model = model
  end
end


The class MyClass will then iterate over the Models attributes etc.

Also I will need to know each attributes data type in mysql like: integer,
boolean, etc.

So my unit tests shouldnt'' rely on the database, but I''m a
little confused
on how I can create stub/mock that will have attributes on it similiar to
how it would be if I was creating a model and it reading the mysql columns
as attributes.

Thoughts on how I can do this w/o actually having to depend on a database
for my spec tests?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20120923/52187fc2/attachment.html>

On Sun, Sep 23, 2012 at 7:55 PM, S Ahmed <sahmed1020 at gmail.com>
wrote:
> I have a class that takes a class that inherits from activerecord as a
> parameter, e.g.:
>
> class SomeModel < ActiveRecord::Base
> end
>
> class MyClass
>   attr_accessor :model
>   def initialize(model)
>     @model = model
>   end
> end
>
>
> The class MyClass will then iterate over the Models attributes etc.
>
> Also I will need to know each attributes data type in mysql like: integer,
> boolean, etc.
>
> So my unit tests shouldnt'' rely on the database, but I''m
a little confused
> on how I can create stub/mock that will have attributes on it similiar to
> how it would be if I was creating a model and it reading the mysql columns
> as attributes.
>
> Thoughts on how I can do this w/o actually having to depend on a database
> for my spec tests?
There is a guideline that says "Don''t mock types you
don''t own," which
I''ve just learned was coined by my colleague at DRW, Joe Walnes [1].

In this case, this guideline suggests that you stub/mock MyClass in
tests for the objects that interact with it, thereby isolating _them_
from the database, but that the tests for MyClass itself are allowed
to interact w/ the database through the AR model. This limits your
dependency on AR to MyClass and its tests, so changes to ActiveRecord
and/or decisions to move to a different database abstraction don''t fan
out very far.

Make sense?

Make sense?

Yes, I think I get it.

The actual class can interact since it is kinda necessary and vital to
testing int anyhow, but when other classes are depending on MyClass, you
can stub/mock since they are outside the scope or domain of the MyClass, so
they shouldn''t have to be depending on the dependancies of Myclass.

On Sun, Sep 23, 2012 at 8:31 PM, David Chelimsky <dchelimsky at
gmail.com>wrote:
> On Sun, Sep 23, 2012 at 7:55 PM, S Ahmed <sahmed1020 at gmail.com>
wrote:
> > I have a class that takes a class that inherits from activerecord as a
> > parameter, e.g.:
> >
> > class SomeModel < ActiveRecord::Base
> > end
> >
> > class MyClass
> >   attr_accessor :model
> >   def initialize(model)
> >     @model = model
> >   end
> > end
> >
> >
> > The class MyClass will then iterate over the Models attributes etc.
> >
> > Also I will need to know each attributes data type in mysql like:
> integer,
> > boolean, etc.
> >
> > So my unit tests shouldnt'' rely on the database, but
I''m a little
> confused
> > on how I can create stub/mock that will have attributes on it similiar
to
> > how it would be if I was creating a model and it reading the mysql
> columns
> > as attributes.
> >
> > Thoughts on how I can do this w/o actually having to depend on a
database
> > for my spec tests?
>
> There is a guideline that says "Don''t mock types you
don''t own," which
> I''ve just learned was coined by my colleague at DRW, Joe Walnes
[1].
>
> In this case, this guideline suggests that you stub/mock MyClass in
> tests for the objects that interact with it, thereby isolating _them_
> from the database, but that the tests for MyClass itself are allowed
> to interact w/ the database through the AR model. This limits your
> dependency on AR to MyClass and its tests, so changes to ActiveRecord
> and/or decisions to move to a different database abstraction don''t
fan
> out very far.
>
> Make sense?
>
> Make sense?
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20120923/90eb473e/attachment.html>

On Sun, Sep 23, 2012 at 8:56 PM, S Ahmed <sahmed1020 at gmail.com>
wrote:
> Yes, I think I get it.
>
> The actual class can interact since it is kinda necessary and vital to
> testing int anyhow, but when other classes are depending on MyClass, you
can
> stub/mock since they are outside the scope or domain of the MyClass, so
they
> shouldn''t have to be depending on the dependancies of Myclass.
That''s basically it.
>
> On Sun, Sep 23, 2012 at 8:31 PM, David Chelimsky <dchelimsky at
gmail.com>
> wrote:
>>
>> On Sun, Sep 23, 2012 at 7:55 PM, S Ahmed <sahmed1020 at
gmail.com> wrote:
>> > I have a class that takes a class that inherits from activerecord
as a
>> > parameter, e.g.:
>> >
>> > class SomeModel < ActiveRecord::Base
>> > end
>> >
>> > class MyClass
>> >   attr_accessor :model
>> >   def initialize(model)
>> >     @model = model
>> >   end
>> > end
>> >
>> >
>> > The class MyClass will then iterate over the Models attributes
etc.
>> >
>> > Also I will need to know each attributes data type in mysql like:
>> > integer,
>> > boolean, etc.
>> >
>> > So my unit tests shouldnt'' rely on the database, but
I''m a little
>> > confused
>> > on how I can create stub/mock that will have attributes on it
similiar
>> > to
>> > how it would be if I was creating a model and it reading the mysql
>> > columns
>> > as attributes.
>> >
>> > Thoughts on how I can do this w/o actually having to depend on a
>> > database
>> > for my spec tests?
>>
>> There is a guideline that says "Don''t mock types you
don''t own," which
>> I''ve just learned was coined by my colleague at DRW, Joe
Walnes [1].
>>
>> In this case, this guideline suggests that you stub/mock MyClass in
>> tests for the objects that interact with it, thereby isolating _them_
>> from the database, but that the tests for MyClass itself are allowed
>> to interact w/ the database through the AR model. This limits your
>> dependency on AR to MyClass and its tests, so changes to ActiveRecord
>> and/or decisions to move to a different database abstraction
don''t fan
>> out very far.
>>
>> Make sense?
>>
>> Make sense?
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users