Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>In this sort of situation, I wouldn't verify the calls to @db because those are read-only calls, so I really don't care if they happen or not. Yes, of course they do have to happen (otherwise where is the data coming from), but I don't think of it as an explicit requirement on the behavior of WishlistReporter... If WishlistReporter could produce the report without talking to the database that'd be perfectly fine by me.</p> <p>I would use <code>db.stub!</code> instead of <code>db.should_receive</code> and be perfectly happy with that.</p> <p>But for cases where the calls to the object being mocked have side-effects and <em>are</em> explicit requirements, I do something like this. (In this example, for whatever reason we require that the db object be instructed to reload its data before we query it.) Again, the methods that are returning the data don't need to be explicitly verified, since if the report output is correct, then the data must have been pulled from @db correctly:</p> <pre><code>describe WishlistReporter do before(:each) do @db = double("database") @db.stub!(:reload_data_from_server) @db.stub!(:categories).and_return(["C1"]) @db.stub!(:items).with("C1").and_return(["I1", "I2"]) @db.stub!(:subitems).with("I1").and_return(["S1", "S2"]) @db.stub!(:subitems).with("I2").and_return(["S3", "S4"]) @output = StringIO.new @subject = WishlistReporter.new(@db) end it "should reload data before generating a report" do @db.should_receive(:reload_data_from_server) @subject.report(:text, @output) end it "should output a report" do @subject.report(:text, @output) @output.seek(0) @output.read.should =~ /stuff/ end end </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POIs there any way to avoid combining many tests into one example, when using mocks?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USavh
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POIs there any way to avoid combining many tests into one example, when using mocks?
      singulars
      1. PTQuestion
    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. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    1. CODamn: you're right. I shouldn't care where Reporter gets the data from. Which makes my `expect`s into `stub`s, which makes more sense of Solnic's answer, too. I'm going to note that the situation I describe above is a "spec code smell". And that `expects` can code you into some nasty corners if you are not careful. Thank you.
      singulars
      1. PO
      1. USAndy
 

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