Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>10 seconds is a very long time for any single test to run. My gut feeling is that your spec target is running both unit and integration tests at the same time. This is a typical thing that projects fall into and at some stage, you <em>will need to overcome this technical debt</em> if you want to produce more, faster. There are a number of strategies which can help you to do this... and I'll recommend a few that I have used in the past.</p> <p><strong>1. Separate Unit From Integration Tests</strong></p> <p>The first thing I would do is to separate unit from integration tests. You can do this either by:</p> <ol> <li>Moving them (into separate folders under the spec directory) - and modifying the rake targets</li> <li>Tagging them (rspec allows you to tag your tests)</li> </ol> <p>The philosophy goes, that you want your regular builds to be quick - otherwise people won't be too happy to run them often. So get back to that territory. Get your regular tests to run quick, and use a continuous integration server to run the more complete build.</p> <p>An integration test is a test that involves external dependencies (e.g. Database, WebService, Queue, and some would argue FileSystem). A unit test just tests the specific item of code that you want checked. It should run fast (9000 in 45 secs is possible), i.e. most of it should run in memory.</p> <p><strong>2. Convert Integration Tests To Unit Tests</strong></p> <p>If the bulk of your unit tests is smaller than your integration test suite, you have a problem. What this means is that inconsistencies will begin to appear more easily. So from here, start creating more unit tests to replace integration tests. Things you can do to help in this process are:</p> <ol> <li>Use a mocking framework instead of the real resource. Rspec has an inbuilt mocking framework.</li> <li>Run rcov on your unit test suite. Use that to gauge how thorough your unit test suite is.</li> </ol> <p>Once you have a proper unit test(s) to replace an integration test - remove the integration test. Duplicate testing only makes maintenance worse.</p> <p><strong>3. Don't Use Fixtures</strong></p> <p>Fixtures are evil. Use a factory instead (machinist or factory_girl). These systems can build more adaptable graphs of data, and more importantly, they can build in-memory objects which you can use, rather than load things from an external data source.</p> <p><strong>4. Add Checks To Stop Unit Tests Becoming Integration Tests</strong></p> <p>Now that you have faster testing in place, time to put in checks to STOP this from occurring again.</p> <p>There are libraries which monkey patch active record to throw an error when trying to access the database (UnitRecord).</p> <p>You could also try pairing and TDD which can help force your team to write faster tests because:</p> <ol> <li>Somebody's checking - so nobody gets lazy</li> <li>Proper TDD requires fast feedback. Slow tests just make the whole thing painful.</li> </ol> <p><strong>5. Use Other Libraries To Overcome The Problem</strong></p> <p>Somebody mentioned spork (speeds up load times for the test suite under rails3), hydra/parallel_tests - to run unit tests in parallel (across multiple cores).</p> <p>This should probably be used LAST. Your real problem is all the way in step 1, 2, 3. Solve that and you will be in a better position to role out additional infrastructure.</p>
    singulars
    1. This table or related slice is empty.
    1. POSpeeding up RSpec tests in a large Rails application
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USBlueFish
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POSpeeding up RSpec tests in a large Rails application
      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. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COFantastic answer :)
      singulars
      1. PO
      1. USMichael Durrant
    2. COGreat answer. It is very true that no advanced tools can help run bad tests quickly. So try writing only good ones.
      singulars
      1. PO
      1. USYura Omelchuk
 

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