in reply to Mock Test Cases

What do you want to test? I assume you mean you have some server side code that generates dynamic pages and you want to test that code. That being the case there are several ways you can approach the problem:

  1. Use Selenium for black box testing - poke the web UI and see what happens. WWW::Selenium may help (I've not used it).
  2. Fake a CGI context for your entire script and test offline. CGI::Test looks like the sort of tool to help in this mode.
  3. Use traditional unit test tools to test functional sections of your code, maybe using Test::MockDBI to mock up database stuff.
  4. Other techniques I've not thought of using some of the plethora of cpan test modules.
Perl is the programming world's equivalent of English

Replies are listed 'Best First'.
Re^2: Mock Test Cases
by boftx (Deacon) on Nov 03, 2014 at 07:19 UTC

    Don't forget Test::MockModule

    You must always remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
[reply]
Re^2: Mock Test Cases
by arora.ajay06 (Initiate) on Nov 03, 2014 at 09:19 UTC

    Thanks GrandFather,

    Actually my scenario is that I am having an Rpc which is called from web UI and in that Rpc i am having some other functions which is creating dynamic queries from different functions and then executed on DB.

    Below is the link which helped me somewhere to mock unit test cases.

    http://www.perl.com/pub/2005/02/10/database_kata.html

    But this has limitations i guess that it won't work in case of dynamic queries.

    Please Suggest.

[reply]

      I've used DBD::Mock, but not DBI::Mock. Using a mock database allows much better control over database failure handling than you can generally achieve with a real database. So they are the tools to turn to when you want to see that your code handles an insertion failure or a lost connection, or other database server side issues that your code need to manage.

      Using a real database is a better tool for testing your business logic. If your code is fairly database agnostic you can even use things like DBD::CSV to wrap text files containing the database data. Simple diffs against reference versions of the file let you check that the database is updated as expected. Dealing with text files also has the advantage that diffs between version in your revision control system make sense.

      Test::Mock::Class works well to wrap a shim around other modules so the tested code doesn't need to be switched to "Test mode".

      Writing the tests can be a lot of work. Test driven development makes it easier to incorporate test development into the general development process and makes it harder to miss important areas of testing.

      Perl is the programming world's equivalent of English
[reply]

In Section Seekers of Perl Wisdom