Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>This is indeed an interesting question, which I sometimes heard from testing newbies. In my opinion, Moles/Typemock are not really comparable to mocking frameworks, and they are surely not a replacement. Here are my top arguments for it:</p> <ul> <li>While it's worth every penny, Typemock comes with considerable initial license costs (~$800 per seat), why some managers hesitate to invest this amount of money. Moles on the other hand is free, but requires quite some work to set up a Moles assembly and comes with a quite strange 'API', which is very hard to learn - especially if you are totally new to testing.</li> <li>Typemock and Moles are not 'Mocking frameworks' in the strict sense - they are some sort of profilers, which use runtime instrumentation under the hood. Thus, they come with a quite hefty performance impact. I have no concrete figures on that, but from my own experience I'd estimate that instrumented tests are around 100-400% slower (Typemock seeming to be faster than MS Moles)! With a large test battery containing thousands of tests, this may be an impediment in itself.</li> <li>Last not least, the killer argument: A mocking framework forces you not only to use interfaces, <strong>but forces you to apply a highly decoupled and maintainable design</strong> on your software (along the lines of <a href="http://en.wikipedia.org/wiki/SOLID" rel="noreferrer">SOLID</a>). - And remember: It's not the initial writing of the software, that primarily accounts for its costs, but it's the maintenance! - With Typemock or Moles, you basically can do whatever you want, and this really is a bad thing and the main argument against developing with Typemock or Moles.</li> </ul> <p>Conclusion: </p> <ul> <li>If you want to cover a brownfield project with tests, which was not written at all with testability in mind, then you have to use one of Typemock or Moles (in my opinion, Typemock is the better choice).</li> <li>If you're starting a new project (i.e. you're doing a greenfield project), then use a mocking framework (I personally like <a href="http://code.google.com/p/moq/" rel="noreferrer">Moq</a> because of its simplicity) and use MS Moles as a complementary for things you can't have an interface for (e.g. .NET framework types).</li> </ul> <p>Even Roy Osherove, the lead dev of Typemock, puts it that way (hopefully he's not getting into trouble with his boss because of this): <a href="http://weblogs.asp.net/rosherove/archive/2010/09/29/a-customer-switches-to-moq-and-i-m-happy.aspx" rel="noreferrer">A customer switches to MOQ – and I’m happy</a></p> <p>There's one exception, though: If learning Test-driven development from scratch, it may be beneficial to use Typemock even for new code. This way, you can significantly flatten the TDD learning curve...</p> <p>Thomas</p>
    singulars
    1. This table or related slice is empty.
    1. POAre Using Interfaces Soley to Facilitate Stubing and Mocking in Unit Tests Now Obsolete?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USThomas Weller
    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. COI'm all for using Interfaces when the architecture of the project would benefit from loose coupling (i.e. layers, DI w/ IoC containers, AOP, etc). What I am referring more to with regards this question is when the architecture doesn't call for an interface and the only reason for adding one is for mocking. I know you could say that I still have more flexibility, but what about the YAGNI principle?
      singulars
      1. PO
      1. USMatt
    2. COWell, for me personally there's always to sides to source code: Production code and test code. Code without at least one covering test is just not complete, so YAGNI is just not an issue. The architecture may not force you to have an interface, but the ability to write test code does.
      singulars
      1. PO
      1. USThomas Weller
    3. COI want to vote up this answer, but the "If learning Test-driven development from scratch, it may be beneficial to use Typemock even for new code" part doesn't let me. I'd be afraid that doing that won't help the developer develop the design skills that you are encouraged to when doing TDD. I'd remove it altogether, since you already mentioned "If you want to cover a brownfield project with tests, which was not written at all with testability in mind, then you have to use one of Typemock or Moles"
      singulars
      1. PO
      1. USeglasius
 

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