5

I've written some code that performs some action, depending on the day of the year and the year. There are an infinite number of years, hence an infinite number of days?

What's a good way to unit test my code? I'd like to cover all of my cases, but since there are an infinite number of them, how can I cover a sufficient amount to know my code works?

(In my case, I'm using the SenTest framework,I'm working in Xcode, 4.5 and I'm targeting iOS.)

Moshe
  • 153
  • 4
  • You need to be able to test the code as if the current date (and time) is any value that you need to test with. Testing leap day calculations once every 4 years is not satisfactory. Thus, you need to ensure your test harness (and the code under test) can work with a controllable time generator (as well as working with the 'normal' time functions). For many purposes, you can regard time as running from, say, 1800 through to 4000; you want to test some non-leap years (like 1800 and 1900 and 2100), as well as leap years like 2000 and 2400. You want to test beginnings and ends of the years. –  Nov 27 '12 at 05:43
  • 3
    Sounds like a good case for 'data-driven' unit testing. Specify the input and expected output in a table. Then you can list all the edge cases that you think need to be tested, as well as the 'happy-path' cases. And a code coverage tool can help to check that your tests cover all the code you have written. –  Nov 27 '12 at 08:42
  • Here is a link for this http://msdn.microsoft.com/en-us/library/ms182527.aspx –  Nov 27 '12 at 12:34
  • @CheGueVerra - Thanks for the link, although the question didn't state which unit-testing framework was being used. –  Nov 27 '12 at 13:30
  • Maybe it would be a good idea to have and additional suite of tests that would stress your application with random input data. AFAIK Lucene/Solr guys took that approach and they even opensourced they own framerwork for randomized testing. http://labs.carrotsearch.com/randomizedtesting.html http://vimeo.com/32087114 –  Nov 27 '12 at 12:31
  • @GarethOwen, I noticed, but that was my starting point for data-driven testing. A good programmer could abstract the tools used and adapt it to his own, IMHO. – CheGueVerra Nov 27 '12 at 14:15

2 Answers2

3

Welcome to SQA, Moshe. There is more than one way to approach this. One technique is to choose a random sample from a pool of possible dates. Judging from your question, you do not need to worry about dates from the Precambrian era, the Renaissance, or the distance future -- just dates for which your application is likely to be used.

If your tests are sufficiently fast, you can try every date over a range that contains enough variety to cover whatever special cases you care about: leap years, weekends, bank holidays, and so on.

If there are special cases in multiple dimensions (e.g. Thursdays get special treatment, except not alternating months during leap years), you might consider a combinatorial approach. If there are so many dimensions that a combinatorial approach becomes unmanageable, there are ways to address that too.

A white box approach would be to find dates that cover every code path.

On a more practical note, even if you choose to put your test cases in a table, you may want to document the purpose of each test case so that you will remember them later.

By the way, this kind of problem extends beyond date-based testing. Any good tester needs to worry about choosing input values from a large pool of possible values.

Community
  • 1
  • 1
    Exactly, the point is to understand how the system treats the data, group data for which system should perform in a similar way, and choose from each group a case to test. That is equivalence partitioning and would be a point to start from. – dzieciou Nov 27 '12 at 16:10
1

Experience is that not setting limits on inputs to functions will create problems. My suggestion is to decide on a range of years and raise an exception on input values outside that range. This allows you to test carefully at the limits and then get a reasonable coverage inside the designed range.

ghellquist
  • 191
  • 2