Databases
StackOverflow2013
Postsdbo
POTesting: how to focus on behavior instead of implementation without losing speed?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POTesting: how to focus on behavior instead of implementation without losing speed?
    primarykey
    data
    text
    <p>It seems, that there are two totally different approaches to testing, and I would like to cite both of them.</p> <p>The thing is, that those opinions were stated 5 years ago (2007), and I am interested, what has changed since then and which way should I go.</p> <p><a href="http://opensoul.org/blog/archives/2007/06/20/rspec-is-getting-too-intimate-with-my-code/" rel="noreferrer">Brandon Keepers</a>:</p> <blockquote> <p>The theory is that tests are supposed to be agnostic of the implementation. This leads to less brittle tests and actually tests the outcome (or behavior).</p> <p>With RSpec, I feel like the common approach of completely mocking your models to test your controllers ends up forcing you to look too much into the implementation of your controller.</p> <p>This by itself is not too bad, but the problem is that it peers too much into the controller to dictate how the model is used. Why does it matter if my controller calls Thing.new? What if my controller decides to take the Thing.create! and rescue route? What if my model has a special initializer method, like Thing.build_with_foo? My spec for behavior should not fail if I change the implementation.</p> <p>This problem gets even worse when you have nested resources and are creating multiple models per controller. Some of my setup methods end up being 15 or more lines long and VERY fragile.</p> <p>RSpec’s intention is to completely isolate your controller logic from your models, which sounds good in theory, but almost runs against the grain for an integrated stack like Rails. Especially if you practice the skinny controller/fat model discipline, the amount of logic in the controller becomes very small, and the setup becomes huge.</p> <p>So what’s a BDD-wannabe to do? Taking a step back, the behavior that I really want to test is not that my controller calls Thing.new, but that given parameters X, it creates a new thing and redirects to it.</p> </blockquote> <p>David Chelimsky:</p> <blockquote> <p>It’s all about trade-offs.</p> <p>The fact that AR chooses inheritance rather than delegation puts us in a testing bind – we have to be coupled to the database OR we have to be more intimate with the implementation. We accept this design choice because we reap benefits in expressiveness and DRY-ness.</p> <p>In grappling with the dilemma, I chose faster tests at the cost of slightly more brittle. You’re choosing less brittle tests at the cost of them running slightly slower. It’s a trade-off either way.</p> <p>In practice, I run the tests hundreds, if not thousands, of times a day (I use autotest and take very granular steps) and I change whether I use “new” or “create” almost never. Also due to granular steps, new models that appear are quite volatile at first. The valid_thing_attrs approach minimizes the pain from this a bit, but it still means that every new required field means that I have to change valid_thing_attrs.</p> <p>But if your approach is working for you in practice, then its good! In fact, I’d strongly recommend that you publish a plugin with generators that produce the examples the way you like them. I’m sure that a lot of people would benefit from that.</p> </blockquote> <p><a href="http://railsforum.com/viewtopic.php?id=6528" rel="noreferrer">Ryan Bates</a>:</p> <blockquote> <p>Out of curiosity, how often do you use mocks in your tests/specs? Perhaps I'm doing something wrong, but I'm finding it severely limiting. Since switching to rSpec over a month ago, I've been doing what they recommend in the docs where the controller and view layers do not hit the database at all and the models are completely mocked out. This gives you a nice speed boost and makes some things easier, but I'm finding the cons of doing this far outweigh the pros. Since using mocks, my specs have turned into a maintenance nightmare. Specs are meant to test the behavior, not the implementation. I don't care if a method was called I just want to make sure the resulting output is correct. Because mocking makes specs picky about the implementation, it makes simple refactorings (that don't change the behavior) impossible to do without having to constantly go back and "fix" the specs. I'm very opinionated about what a spec/tests should cover. A test should only break when the app breaks. This is one reason why I hardly test the view layer because I find it too rigid. It often leads to tests breaking without the app breaking when changing little things in the view. I'm finding the same problem with mocks. On top of all this, I just realized today that mocking/stubbing a class method (sometimes) sticks around between specs. Specs should be self contained and not influenced by other specs. This breaks that rule and leads to tricky bugs. What have I learned from all this? Be careful where you use mocking. Stubbing is not as bad, but still has some of the same issues.</p> <p>I took the past few hours and removed nearly all mocks from my specs. I also merged the controller and view specs into one using "integrate_views" in the controller spec. I am also loading all fixtures for each controller spec so there's some test data to fill the views. The end result? My specs are shorter, simpler, more consistent, less rigid, and they test the entire stack together (model, view, controller) so no bugs can slip through the cracks. I'm not saying this is the "right" way for everyone. If your project requires a very strict spec case then it may not be for you, but in my case this is worlds better than what I had before using mocks. I still think stubbing is a good solution in a few spots so I'm still doing that.</p> </blockquote>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USkrn
    1. USkrn
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POTesting: how to focus on behavior instead of implementation without losing speed?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POTesting: how to focus on behavior instead of implementation without losing speed?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POTesting: how to focus on behavior instead of implementation without losing speed?
      1. This table or related slice is empty.
      1. VTUpMod
    1. COIt is a good question; I have seen a lot of brittle unit tests as a result of all the mocking that is going on. JavaScript unit tests can be worse.
      singulars
      1. POTesting: how to focus on behavior instead of implementation without losing speed?
      1. USJason Capriotti
    2. COMan, I like all of these thoughts! The biggest problem here is probably Rails. In GOOS, they say you shouldn't mock third party code (which they would include ActiveRecord), because you can't make design changes which affect it. That's essentially the problem, David points out that he would rather use composition, but can't b/c AR chose inheritance (if he wants to do things as traditionally done in Rails). Personally, I have a lot of ideas, and I don't know which are right. Good question, though.
      singulars
      1. POTesting: how to focus on behavior instead of implementation without losing speed?
      1. USJoshua Cheek
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload