test cases for methods signatures

Question

I have a program and I was looking for a more formal way to test it, I read about test cases, and I dont know if I understnad correctly.

For example I have a program where I have some methods signatures, for example the registerSale and editProductPrice. And I would like to test and I read about test cases for this. And for what I understood we need to have inputs and than the expected output.

So, for example the first method to register a sale receives a array of product ids and a array with the quantity of each product, the method signature is:

public boolean registerSale(ArrayList<Integer> prodId,ArrayList<Integer> quantityOfEachProduct)

So some test cases I think would be:

Input                                                       Output

(prodId.add(10,7,20),quantityOfEachProduct.add(2, 4, 1))    10-2,7-4,20-1
(prodId.add(20,2),quantityOfEachProduct.add(4, 7))          20-4,2-7         
(prodId.add(-4,-10),quantityOfEachProduct.add(2,4))         error                             

And for this method signature, has with inputs the product id and the price.

public boolean editProductPrice(int idProduct, float price);

So I think would be something like this:

 Input                                                       Output

   (4, 10.50)                                                (4,10.50)
   (10, 7.77)                                                (10,7.77)

Do you know if that is the way to do correct test cases for methods?

Answer 1

Input - Output testing is one of the most popular ways to test. It's simple, easy and straightforward.

If you can wrap your brain around it though Property Based testing is a far more reliable and useful way of testing.

Some of the properties I am seeing:

First Method:

1. ProductID must always be a positive integer
2. Quantity Sold must always be an integer
3. The response should always contain the ProductID-Qty in a CSV format of the request

Second Method:

1. Input should always match the output
2. A verification of the price should match the price used when updating
3. The ProductID should only accept a positive integer
4. The price should only accept a decimal value (probably also a positive number here as well).

By focusing on the properties being tested and not the input/output, you get a clearer whole picture of the system and can use any input and verify the output.

For some more information on this type of testing, there is quite a few resources online but the one that I have read and re-read the most is here.