Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>However, as mock objects simply mimic the behavior of the real objects, isn't the in-container testing the only way to really test the system in its' real environment?</p> </blockquote> <p>I think the short answer is yes, but... I think your "categorization of integration test" question is very relevant. Unit and integration tests are <em>both</em> important although the serve different functions.</p> <p>Unit tests are closely associated with the code, should startup and run very fast, should be run often by developers iterating on the code, and usually use mocks to a high degree. The idea is to test the code in question, not its dependencies or integration points. The problem with making the unit tests all be in-container is that they will be run less often or they will waste too much developer time.</p> <p>We have isolated our in-container/integration tests elsewhere in another project with dependencies on the code projects. They are designed to closely mimic production configurations -- as much as possible. These tests take longer to setup, run longer, and are more useful to run by something like <a href="http://cruisecontrol.sourceforge.net/" rel="nofollow noreferrer">cruisecontrol</a>. They are run by hand especially when we are closing in on a release or after development has stabilized. Often I fire up the integration tests when I'm going to lunch or a meeting. When an integration test discovers a bug, we try to write a unit test that also demonstrates the bug with the mocks -- this is often hard and can be impossible.</p> <p>We usually have a couple small in-container tests with the unit tests just to make sure that the spring wiring works or to test some basic functionality but the rest of the integration testing is done in another project.</p> <p>All this said, there is not a firm difference between the two. Sometimes we move unit tests that just deal with a lot of data and take a long time out to integration tests and sometimes integration tests run fast enough and are valuable enough to be included along with the code.</p>
    singulars
    1. This table or related slice is empty.
    1. POIn-container testing vs. mock objects for integration testing
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USGray
    1. USGray
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POIn-container testing vs. mock objects for integration testing
      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. VTAcceptedByOriginator
    1. COI am perfectly fine running unit tests out of container. Actually, I don't understand why you are running "a couple small in-container unit tests" to test "Spring wiring" and stuff? Maybe you typoed in there, did you mean "a couple small in-container *integration tests*"? Also, do I understand correctly: if there is a change to your runtime configuration, you have to copy that settings to the integration-test project? How do you actually run/initialize the in-container tests? With an aid from some framework maybe?
      singulars
      1. PO
      1. USTuukka Mustonen
    2. COI've edited the section. I meant that we have a couple integration tests in our collection of unit tests to make sure that all of the Spring wiring works. All of the configuration files are with the code -- we do not copy any configurations over to the integration projects. The integration project shares the same package paths as the production code so can load all of the same src/main/resource (we're using mvn) configs.
      singulars
      1. PO
      1. USGray
 

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