[rspec-users] Weird failing spec

Ashley Moran work at ashleymoran.me.uk
Sat Oct 27 07:04:45 EDT 2007


On Oct 27, 2007, at 9:45 am, Tarsoly András wrote:

> This raises up a question in me about mocking or using real-life
> models, because in some of my specs the setups getting extremely
> bulky. But this is for another topic :)

Well while you have everyone's attention :)

Often you can factor out the setup code - if you search through the  
archives of this list there's plenty of examples.  But don't worry  
about having long setups - I've written some setups that aren't much  
shorter than the specs that follow.  Write whatever setup you need to  
enable you to write solid specs, then worry after about making it  
look nice.

I would say you should ALWAYS mock your models in your controllers  
specs.  Otherwise you will further complicate your setups, make your  
specs run unacceptably slow, and you risk coupling your controllers  
and models too tightly.  Many people in the BDD community (and at a  
guess I am assuming David is among them) would frown on using  
database access in your *model* code, because persistence is a  
separate issue to business logic.

What you want is a set of specs for each of model (ideally, database  
persistence and business logic separately), controller, and view, and  
then an integration test, such as an RSpec story, that tests the full  
stack.  Without this integration step, you will miss errors when you  
change the interface of a model.  What you do not want is the Rails  
way of testing, where each layer of testing re-tests everything below  
it.  (I recently saw a blog post where someone asked for comments on  
how people test views in isolation - it never occurred to me that  
some Rails developers still see that as an issue!)

Having thought about it, you could argue Rail has no *unit* testing  
support built in at all.

Ashley


-- 
blog @ http://aviewfromafar.net/
linked-in @ http://www.linkedin.com/in/ashleymoran
currently @ home




More information about the rspec-users mailing list