I am currently writing a simple, timer based mini app in C# that performs an action n times every k seconds.
I am trying to adopt a test driven development style, so my
I think what I would do in this case is test the code that actually executes when the timer ticks, rather than the entire sequence. What you really need to decide is whether it is worthwhile for you to test the actual behaviour of the application (for example, if what happens after every tick changes drastically from one tick to another), or whether it is sufficient (that is to say, the action is the same every time) to just test your logic.
Since the timer's behaviour is guaranteed never to change, it's either going to work properly (ie, you've configured it right) or not; it seems to be to be wasted effort to include that in your test if you don't actually need to.
What I have done is to mock the timer, and also the current system time, that my events could be triggered immediately, but as far as the code under test was concerned time elapsed was seconds.
Len Holgate has a series of 20 articles on testing timer based code.
I agree with Danny insofar as it probably makes sense from a unit-testing perspective to simply forget about the timer mechanism and just verify that the action itself works as expected. I would also say that I disagree in that it's wasted effort to include the configuration of the timer in an automated test suite of some kind. There are a lot of edge cases when it comes to working with timing applications and it's very easy to create a false sense of security by only testing the things that are easy to test.
I would recommend having a suite of tests that runs the timer as well as the real action. This suite will probably take a while to run and would likely not be something you would run all the time on your local machine. But setting these types of things up on a nightly automated build can really help root out bugs before they become too hard to find and fix.
So in short my answer to your question is don't worry about writing a few tests that do take a long time to run. Unit test what you can and make that test suite run fast and often but make sure to supplement that with integration tests that run less frequently but cover more of the application and its configuration.