Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>This is actually a good question because when I started out with test cases, I wasn't sure what is considered a good test case. Here are a few things which you can follow. This list is not mine; but compiled from a few sources plus some of my additions.</p> <p><strong>Describe methods</strong></p> <p>While describing methods, it is a good practice actually describe your method like: describe "#admin?" etc. "." is a prefix for class method and "#" is a prefix for instance methods.</p> <p><strong>One assert per test case</strong></p> <p>Make sure that you have just one assertion per test case. This makes sure that your test cases are clean and easy to understand; which is the point of test cases, isn't it? :)</p> <p><strong>Avoid saving data to db</strong></p> <p>You can dynamically build objects to and avoid saving data to db. Although you can clean up the db before each test case, "not saving" will speed up test cases in a big way.</p> <p>@user.build(:something) instead of @user.create(:something)</p> <p><strong>Edge and Invalid cases</strong></p> <p>This is not specific to Rspec but it is important to make sure edge cases are covered in testing. This helps greatly later on when your project grows and it gets easy to maintain.</p> <p><strong>contexting</strong></p> <p>I, personally, like this a lot in Rspec and I in fact overuse contexts a bit. Using contexts with conditions helps in compartmentalizing your test cases. Here's an example:</p> <pre><code># Avoid it "should have 200 status code if user is logged in" do response.should respond_with 200 end it "should have 401 status code if user is not logged in" do response.should respond_with 401 end # Use context "when user is logged in" do it { should respond_with 200 } end context "when user is logged out" do it { should respond_with 401 } end </code></pre> <p><strong>Using subject</strong></p> <p>When you have lots of test cases which are related to the same thing, you can use subject() to make sure you don't repeat yourself.</p> <pre><code># Avoid it { assigns(:user).should be_valid } it { assigns(:user).should_not be_dumb } it { assigns(:user).should be_awesome } # Use subject { assigns("user") } it { should be_valid } it { should_not be_dumb } it { should be_awesome } </code></pre> <p>Here are a few things that I try to follow when I write test cases. I'm sure there are a lot more things which can improve Rspec test cases. But this should be enough to get started and write awesome test cases.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhat is considered a good spec? Rspec examples for beginners
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USsandeep
    1. USsandeep
    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. CO+1 @sandeep this is awesome :)
      singulars
      1. PO
      1. USbotbot
 

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