Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>That statement means:</p> <p>Stub the <code>new</code> method on the class <code>Weather</code> with the parameters <code>'these'=&gt;'params'</code> and return the value of the expression <code>mock_weather(:save =&gt; true)</code></p> <p>A similar and perhaps clearer way to write this would be:</p> <p><code>Weather.stub(:new).with({'these'=&gt;'params'}).and_return(mock_weather(:save =&gt; true))</code></p> <p>The syntax <code>{</code>&lt;<code>some code</code>><code>}</code> creates a <a href="http://blog.rubybestpractices.com/posts/gregory/009-beautiful-blocks.html" rel="nofollow noreferrer">code block</a> which is executed when the stub is called.</p> <p>The return values of the two forms <code>.and_return()</code> and <code>{}</code> are slightly different; in the first case it is determined when the stub is defined, in the second case it is determined when the message is received. They are generally interchangeable -- <a href="https://stackoverflow.com/questions/4692483/rspec-newbie-update-attributes-false-not-being-recognised/4695928#4695928">but sometimes not</a>.</p> <p><strong>EDIT</strong></p> <p>I feel <a href="https://stackoverflow.com/questions/4893329/rspec-scaffold-controller-understanding-the-defaults-being-given/4901360#4901360">this answer</a> is misleading about mocks and deserves a response:</p> <blockquote> <p>As for your first question about "how to make it a bit clearer", we could begin by not using mocks. A mock object is useful when you can not depend on a predictable behavior of a secondary object, an object that is not important but must be present in your test case. Typical examples of the usage of mock objects are database queries, network usage, file i/o. You don't want your tests to fail because your computer lost network connection, or a database is not available.</p> </blockquote> <p>True, mocks can eliminate dependencies on external resources, but that is not their only purpose. The real value of mocks is that they allow you to write tests for code that doesn’t exist yet. In Rails for example, you might decide to start by writing the view specs first. </p> <pre><code>describe "posts/show.html.erb" do it "displays the author name" do assign(:post,mock('post',:author=&gt;"Mark Twain")) render rendered.should contain("written by Mark Twain") end end </code></pre> <p>This spec doesn’t require the existence of a database, a controller, or a model. All it does is assert that the view needs to render a string and verify that it gets rendered --which is all that a Rails view is supposed to be concerned with. The only dependencies are the existence of the template file and the instance variable <code>@post</code>, which is handled by the <code>assign</code> statement. It doesn't even care what <code>@post</code> is, only that it responds to <code>:author</code>.</p> <blockquote> <p>The generated code that you got from the rails g scaffold is not optimal. The generated code was generated in a way that will make all tests pass, and for that it uses mock objects. I don't know why they do that, I think a better default would be failing tests so that you actually need to do something to make them pass.</p> </blockquote> <p>The whole idea of a scaffold is to save time by generating code that works for the usual use cases. Wouldn’t you want the generated tests to actually work too?</p> <p>Of course by using scaffolding you are doing an end run around the BDD/TDD “test first” paradigm, but presumably you’ve accepted the tradeoffs involved, or you wouldn’t be using the scaffolds in the first place.</p> <p>As to "why use mock objects", they allow the controller spec to be decoupled from the model and the database. So yes it is "optimal" once you know the reasoning.</p> <blockquote> <p>With the auto generated mock files you don't have to do anything at all and the tests will continue to pass forever. That is a bad idea, and bad practice.</p> </blockquote> <p>They will only pass as long as you don’t break the subject code. So they have value in regression testing to ensure that you are not introducing new code or refactoring in a way that causes the code to no longer meet the specs.</p> <blockquote> <p>Since will have to write the validation rules in your model file, and you are not using a mock object, you can be sure that an actual validation is going on.</p> </blockquote> <p>This kind of coupling is actually undesirable in a Rails controller spec. The controller should know as little as possible about the model, so the controller specs only need to define what happens when validation passes (or fails) -- and the mock provided by the scaffold does exactly that. If you need to test whether a model instance is valid for a given set of parameters, do that in the model specs.</p>
    singulars
    1. This table or related slice is empty.
    1. PORSpec Scaffold Controller, understanding the defaults being given
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USzetetic
    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. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks for the clearer version. I wish they would just use that as the default instead of the other way. The code block URL has been bookmarked and is a great explanation and examples.
      singulars
      1. PO
      1. USalenm
    2. COVery nice explanation.
      singulars
      1. PO
      1. USgerky
 

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