I often find myself writing programs that operate on fairly large datasets and complex problem formulations, which usually take on the order of 30 minutes to 2 days of running to identify a bug. The psychological effect of these long testing iterations can be very taxing, and I find it very difficult to change focus and move my mind off of one program and on to another for the 30-ish minutes that a test is running. What strategies can I employ to ease my mind between tests, and change focus more quickly, to achieve a higher productivity?

  • 1
    Can you create smaller, shorter tests to give you enough confidence in your work to continue development through a course of a day and run these longer tests overnight? It may not do much for tests that are longer than 14 hours, unless you can work on projects on alternating days.
    – Thomas Owens
    Commented Mar 21, 2016 at 18:26
  • Sometimes it is reasonable to be satisfied with smaller tests, however oftentimes it is the very scaling ability which needs to be tested- for these kinds of tests, it is often far from obvious how to reduce them.
    – deftfyodor
    Commented Mar 21, 2016 at 18:29
  • 2
    Which brings me back to my question: if you have smaller, faster tests that prove functionality is correct, why can't you work on a project for a day, while running your faster tests to prove correctness, and run these long tests at night and while working on a second program? Your context switching between programs is reduced if you simply don't run your long-running tests in the day time.
    – Thomas Owens
    Commented Mar 21, 2016 at 18:30
  • You're doing ETL aren't you?
    – RubberDuck
    Commented Mar 22, 2016 at 0:45
  • 1
    I'm voting to close as there are really 2 questions here as I see it: 1) How to retain focus when switching tasks and 2) How to reduce the test time for large datasets.
    – Robbie Dee
    Commented Mar 22, 2016 at 12:12

1 Answer 1


What I would suggest is to keep your daily or compile/build tests as short as possible. Builds and subsequent unit tests should run as quickly as possible. A day to run tests isn't reasonable, even builds running for more than 15 minutes indicate too much code/too big a project/too many time consuming tests being run.

However, I would not abandon those long running tests. Instead I would schedule them to be weekly or monthly as part of larger regression suite of tests. Kick them off on a Friday or Saturday and examine the results on Monday. If weekly isn't a good interval, go every few days.

  • " What strategies can I employ to ease my mind between tests, and change focus more quickly, to achieve a higher productivity?" I don't believe you have answered this question at all but there is certainly mileage in reviewing what to test, how and when.
    – Robbie Dee
    Commented Mar 22, 2016 at 12:14
  • @Robbie - I guess my answer would be, automate everything. While tests are running, I am doing other things, and they run many times throughout the day (during and after every build). All the tests are automated as part of build and/or post deployment activities. Result collection is also automated as well as we get emails and have dashboards up on monitors review test results. The only time I spend on times is maybe fixing a broken on or writing a new one(s). They are part of my day, but are not taxing me mentally.
    – Jon Raynor
    Commented Mar 22, 2016 at 13:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.