Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>When testing GUI or database code with mocks, what are you really testing? Mocks are built to return exactly the answer you want, so how do you know that your code will work with the real-world database? What is the benefit of automated tests for this kind of thing? It improves confidence somewhat, but a) it doesn't give you the same level of confidence that a complete unit test ought to, and b) to a certain extent, aren't you simply verifying that your assumptions work with your code rather than that your code works with the DB or GUI?</p> </blockquote> <p>This is my approach: For database access layer (DAL), I <strong>don't use mock</strong> for my unit test. Instead, I run the tests on a real database, albeit a different one than the production database. So in this sense you can say that I don't run unit test on database. For NHibernate applications, I maintain two databases with same schema, but different database type (<a href="http://en.wikipedia.org/wiki/Object-relational_mapping" rel="nofollow noreferrer">ORM</a> makes this easy). I use <a href="http://www.sqlite.org/" rel="nofollow noreferrer">sqlite</a> for my automated testing, and a real MySQL or SQL server database for ad-hoc testing.</p> <p>Only once did I use mock for unit testing the DAL; and that's when I was using strongly typed dataset as the ORM ( a big mistake!). The way I did this was to have <a href="http://typemock.com" rel="nofollow noreferrer">Typemock</a> returned me a mocked copy of the complete table so that I can perform <code>select *</code> on it. Later as I looked back I wished I never do this, but that was long time ago, and I wished I used a proper ORM. </p> <p>As for the GUI, <strong>it is possible</strong> to unit test the GUI interaction. The way I did this was to use the <a href="http://msdn.microsoft.com/en-us/magazine/cc188690.aspx" rel="nofollow noreferrer">MVP pattern</a> to separate out the Model, View and Presenter. Actually for this type of application I only test on the Presenter and the Model, in which I use Typemock ( or <a href="http://en.wikipedia.org/wiki/Dependency_injection" rel="nofollow noreferrer">dependency injection</a>) to isolate the different layers so that at one time I can concentrate on only one layer. I don't test the view, but I <em>do</em> test Presenter ( where the majority of interaction and bugs are happening) a lot . </p>
    singulars
    1. This table or related slice is empty.
    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. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

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