Bob's pick this week is Atomic reminder by Daniel Armyr.
Contents
Round 1
A few months ago I posted Atomic clock + alarm challenge. Daniel took the challenge and submitted a solution. I like it! His approach uses a timer object. (Great minds think alike.) The command line use of remindme_atom is simple, and the modal pop-up dialog is effective. I also got a kick out of his sound stream when my alarm went off. Nice touch!
Round 2
Did you really think I'd stop there? Now that we have a solution to the previous challenge, the new challenge is to brainstorm a test plan for it. You might start by understanding different ways remindme_atom was intended to be used. How do you make sure it does exactly what it is supposed to do? How many test cases can you think up? How could you accidentally misuse it. Which cases are not worth testing? What steps would you take? Do any other considerations come to mind?
Discussion
Don't jump in head first. Rather, let's talk about how you test code that you write, or M-files from others that you rely on. You do test your own code, somehow, right? Please share your thoughts here.
Get
the MATLAB code
Published with MATLAB® 7.7



I am very interested in hearing about what others do. Especially given the modal dialog - I haven’t found a good way to test scripts that have dialogs, whether Matlab, figure, Java, or Simulink masks.
For other scripts I don’t have a consistent way.
Sometimes I play around with it until I’m satisfied.
Sometimes I have a test script that I may or may not archive.
Sometimes I have the script look for the inputs - if the only input is the string ‘SelfTest’ I call a subfunction that contains all of the test cases, calling the main function recursively. These are usually the best maintained test cases.
Unfortunately, while I’ve used the Profiler to check the performance of the test cases, I usually forget to use the Profiler highlighting to check the coverage of the test cases. Does anyone use the Profiler output for coverage analysis?
Whenever I am developing an algorithm and feel particularly ambitious, I make a test script where each cell is a test case and ends in an assert. That way, I can easilly iterate over any test case that is failing, and finally publish a report when the algorithm is done.
In this case, there are several things that would need testing, all of which are non-trivial.
1) Testing that the getCurrentTimeDelta does the right thing. This is virtually impossible unless one has another atomic clock implementation to compare against, and even so it is difficult.
2)Test that the timer object works properly. This could be done by swapping out the dialog box for something else, setting the atmic delta to 0 and then clocking the time untill our callback is called.
3) Testing that the dialog box works. Plain difficult, as all GUI testing is.
–DA
Thanks for the great comments and some clever ideas. Let’s keep the discussion going…
Does anyone use the profiler for coverage analysis?
Dialogs are indeed pesky critters. Does anyone have a trick for using scripts to verify dialog behavior? Suppose automation is not possible. What are the alternatives?
Daniel provided “white box” insight (not surprisingly) to the modules that need testing. Let’s see if we can list some test cases…