0

I was working on one project and faced the following issue

I created a method in class to find some user and apply logic, it throws an exception if something unexpected is returned else user object either with id null or with some value

I wrote unit test for all test cases , now in callee i forgot to add condition for null id .

What is the best practise to handle these kind of error. Shall i write integration tests with all test cases Or integration test should have only happy path?

Secondly, in integration test, is it good to use embedded database instead of actual db? I was thinking to use embedded database for integration test, but how can i test the queries which are vendor specific, example rownum in oracle and limit in mysql. In my actual env we are using oracle and embedded database i can use h2. I am using plain jdbc

Thanks

Mike Stockdale
  • 5,256
  • 3
  • 29
  • 33
Ramandeep S
  • 325
  • 1
  • 4
  • 15
  • As a general guideline any test (unit or integration) should test all return types and their range of values. An integration test would mimic all aspects of the production code. It could substitute the actual objects with mock objects. See this [link](http://stackoverflow.com/questions/520064/what-is-unit-test-integration-test-smoke-test-regression-test) for details. Not clear what you mean in the last paragraph starting with the 2nd sentence, perhaps clarify? – NameRakes Feb 14 '17 at 02:42
  • Thanks namerakes.. i edited second part of question – Ramandeep S Feb 14 '17 at 02:46

2 Answers2

0

This is what I would do for vendor specific situations - since rownum in Oracle and limit in MySQL both limit the number of rows returned, I would create an abstraction on my side, say, myLimit. Depending on the choice of vendor DB, it maps to either rownum or limit.

Once you have the above, and any other necessary abstractions covering all aspects of your app, you can start to design the integration tests. My recommended preference is: (i) actual DB connection, (ii) embedded DB, and (iii) mock DB, for all vendors. The DB itself does not have to huge.

Based on QA metrics, if you feel that the DB connections are tested thoroughly by other tests, then I would go with just embedded or mock DB in integration tests.

As you can see, the answer depends on how well rest of the system is tested! Good luck.

NameRakes
  • 463
  • 6
  • 12
0

About unit and integration testing.

Let's clarify what is the difference between these types of testing.

Unit testing should be covering unit which means that we are covering quite small piece of code. Thus unit tests are normally covering very specific cases and normally there are a lot of unit tests because for one small method the program might have several directions and all of them should be covered. All the things which are disturbing unit testing, like, for example, some methods which are calling external parties and not really related to the business logic of the method must be mocked.

In Integration testing instead it is not advisable to mock anything because you want to test the whole pipe basically which means that your test should go through different modules (classes) and don't mock anything. This type of tests are normally quite huge, thus, I would advice not to handle some small verification checks within integration tests because from my point of view it is not worth doing that.

If I understand your case correctly from my point of view your method should check for null and not the caller. It is based on the fact that you never know who is going to call your method. Your method should expect all the different values in the input parameters that are allowed.

Rufi
  • 2,529
  • 1
  • 20
  • 41