Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>In my opinion, unit tests should be placed in a separate assembly from production code. Here are just a few cons of placing unit tests in the same assembly or assemblies as production code are:</p> <ol> <li>Unit tests get shipped with production code. The only thing shipped with product code is production code.</li> <li>Assemblies will be unnecessarily bloated by unit tests.</li> <li>Unit tests can affect build processes like automated or continuous build. </li> </ol> <p>I don't really know of any pros. Having an extra project (or 10) isn't a con.</p> <p><strong>Edit: More Info On Build and Shipping</strong></p> <p>I would further recommend that any automated build process place production and unit tests into different locations. Ideally, the unit test build process only runs if the production code builds, and copies the product files into the unit tests directory. Doing it this way results in the actual bits being separated for shipping, etc. Additionally, it is fairly trivial to run automated unit testing at this point on all tests in a particular directory.</p> <p>To summarize, here is the general idea for a daily build and testing and shipping of bits and other files:</p> <ol> <li>Production build runs, placing production files into a specific "production" directory. <ol> <li>Build production projects only.</li> <li>Copy compiled bits and other files into a "production" directory.</li> <li>Copy bits and other files into a release candidate directory, aka a Christmas release directory would be "Release20081225".</li> </ol></li> <li>If production build succeeds, unit test build runs. <ol> <li>Copy production code to "tests" directory.</li> <li>Build unit tests to "tests" directory.</li> <li>Run unit tests.</li> </ol></li> <li>Send build notifications and unit tests results to developers.</li> <li>When a release candidate (like Release20081225) is accepted, ship these bits.</li> </ol>
    singulars
    1. This table or related slice is empty.
    1. PODo you put unit tests in same project or another project?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJason Jackson
    1. USJason Jackson
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PODo you put unit tests in same project or another project?
      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. COIMO the cons you list aren't always applicable. A pro for same-project is easier grouping of tested class + tests - these small conveniences go a long way when writing tests. Personal preference wins here, and sometimes your points are relevant, just not all the time.
      singulars
      1. PO
      1. USorip
    2. CObut how do you remove these projects when you want to ship
      singulars
      1. PO
      1. USleora
    3. COYou should first ask whether you need to remove the tests when you ship. If yes, you need a separate project. If not, use the other pros and cons to decide. People that assume they can't deploy the tests will always reach the "separate project" conclusion by default.
      singulars
      1. PO
      1. USorip
 

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