Where to start writing specs from? Features? Models?

43 views
Skip to first unread message

Askar

unread,
Jul 28, 2015, 12:42:40 AM7/28/15
to rspec
I'm very new to rspec.

Can't figure out where to start writing specs from?

In the Rails 4 in Action they starting from writing in spec/features.
In http://everydayrails.com/ they start from spec/models.
Not sure if there any other approach...

Which approach is recommended?

Aaron Sumner

unread,
Jul 28, 2015, 4:36:41 PM7/28/15
to rspec, askar.k...@gmail.com
Hi Askar, this is Aaron from Everyday Rails. The posts you're referring to, and my book that followed them, were based on how I learned testing. I found testing models to be easier because they didn't require very much setup. Once I got comfortable testing models I moved up to more complex tests. Once I got comfortable with the process of writing tests, I switched to the "top down" approach that it sounds like Ryan covers in Rails 4 in Action. I start with a high level spec (like a feature spec), then I drop down to a lower level spec (like a model spec) when my tests aren't giving me good feedback about my code.

Wherever you start testing, I recommend practicing a lot. I would write tests for simple functionality, and functionality that I already knew was working. Then I would experiment to see happened when I changed things around in the test, and in the application code being tested. Deliberate practice and experimentation are the best ways I've found for learning testing and programming.

Hope that helps,
Aaron

Alex Chaffee

unread,
Jul 28, 2015, 4:36:46 PM7/28/15
to rs...@googlegroups.com
The subdirectory determines what *type* of spec they are -- that is,

either what type of unit they are testing
models, controllers, mailers, etc.

or what test framework they're using
spec/features -> Capybara
spec/javascripts -> Jasmine
etc.

Some RSpec functions are automatically made available to certain types
of spec; e.g. controller specs get `get`, `post`, `put`, methods (to
simulate an HTTP call of the appropriate type).

Start wherever you are! If you're writing a model, write a spec in spec/models.

- A
> --
> You received this message because you are subscribed to the Google Groups
> "rspec" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rspec+un...@googlegroups.com.
> To post to this group, send email to rs...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/41867e14-ce60-4e43-806a-d1740744089c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Alex Chaffee - ale...@gmail.com
http://alexchaffee.com
http://codelikethis.com
http://twitter.com/alexch

Askar Karasaev

unread,
Jul 28, 2015, 8:06:08 PM7/28/15
to Aaron Sumner, rspec
Hi Aaron,

Thanks for reply.
It was me asking you recently on github regarding your book actually. :)

I agree I need to practice. 
As I understood, I can test same things in models and feature specs, so I'm wondering which is better? which is effective?
I think this is main point beginners confuse.

Regards,
Askar

Askar Karasaev

unread,
Jul 28, 2015, 8:06:51 PM7/28/15
to rspec
Hi Alex,

Actually I want to determine where to test, not to be tied to the automatically generated specs.

Cheers,
Askar


--
You received this message because you are subscribed to a topic in the Google Groups "rspec" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rspec/FJcS2697KHA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rspec+un...@googlegroups.com.

To post to this group, send email to rs...@googlegroups.com.

Alex Chaffee

unread,
Jul 30, 2015, 11:06:38 AM7/30/15
to rs...@googlegroups.com, Aaron Sumner
On Tue, Jul 28, 2015 at 8:06 PM, Askar Karasaev
<askar.k...@gmail.com> wrote:
> As I understood, I can test same things in models and feature specs, so I'm
> wondering which is better? which is effective?

Both.

If I understand correctly, feature specs use Capybara which takes a
relatively high-level pass through the app. It tests user input, HTML
output, error handling, that sort of thing. Model specs are focused on
a single object, so they test a wider range of scenarios, call
individual methods, require much less setup, are faster, etc.

I recommend a pyramid of test coverage: the base is unit tests
(including model specs) -- make lots of those, fewer controller tests,
and even fewer integration tests (including capybara).

- A

Askar Karasaev

unread,
Jul 30, 2015, 8:11:43 PM7/30/15
to rspec, Aaron Sumner
Hi Alex,

I thought we should follow DRY concept so that I won't test one thing in more than one method...

By "unit test", do you mean the default test of Rails?

Thanks,
Askar

--
You received this message because you are subscribed to a topic in the Google Groups "rspec" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rspec/FJcS2697KHA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rspec+un...@googlegroups.com.
To post to this group, send email to rs...@googlegroups.com.

Alex Chaffee

unread,
Jul 31, 2015, 9:21:36 AM7/31/15
to rs...@googlegroups.com, Aaron Sumner


Sent from my iPad

On Jul 30, 2015, at 8:10 PM, Askar Karasaev <askar.k...@gmail.com> wrote:

Hi Alex,

I thought we should follow DRY concept so that I won't test one thing in more than one method...

Nope. The threshold for DRY in tests is higher, since tests have to be readable and since their targets can shift out from under them due to refactoring and normal code growth. Some people say tests should be MOIST :-)


By "unit test", do you mean the default test of Rails?

No, test and spec are synonymous. A spec is a test. 

A unit test tests a single unit in isolation. Even Rails model tests are not pure unit tests since they depend on a database, but they come close. 

Back in the day, the big distinction was between unit test and integration test -- the latter tests how a bunch of units work together but doesn't exercise every case of every unit; that's what unit tests are for. 

Basically, a unit test tests the code; an integration test tests the code working together with other units; a functional test tests the product. 

The terms and concepts are slippery but you'll get more comfortable with them with experience. 



You received this message because you are subscribed to the Google Groups "rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rspec+un...@googlegroups.com.

To post to this group, send email to rs...@googlegroups.com.

Askar Karasaev

unread,
Jul 31, 2015, 9:26:25 AM7/31/15
to rspec, Aaron Sumner
Thanks for your time, Alex! ;)
It was very helpful.

Regards,
Askar

Reply all
Reply to author
Forward
0 new messages