5

Unit testing currently takes up more than half my development time, and I'd like to streamline the process, are there any general tips or tricks that will help me write unit tests faster?

I'm currently in the process of creating factories that create test data, and obfuscate it to fit certain conditions, which I hope will make all of this much quicker to code in the future.

Are there any other practices that I should consider?

Improve this question

2 Answers 2

Reset to default
2

One remark up-front: You are very aware of the cost of unit-tests. The yield however is sizeable as well. You cannot do without!

That being said, I have some ideas for you:

  1. What is your goal? Unit-tests should do no more or less than capture you component design. Forget about discovering bugs or detecting regressions.

  2. Keep a low profile. Only target a single component per set of tests. Keep it simple and easy to maintain, too.

  3. Use a framework. It will limit the amount of code to write and help you in a million ways while running the test.

References:
http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/
https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

Improve this answer
4
  • Can you give an example of a tester that captures component design but does not serve for discovering bugs? Can you explain why it is better to discover bugs on other levels?
    – dzieciou
    Jul 1, 2016 at 6:06
  • Tests would simply follow design, and skip exotics like odd exceptions and illegal input etc. So, the lean version of unit-tests. Bugs can also be found with tests that involve more of the system than single components, which is closer to actual use and therefore more realistic, bringing you to shippable quality with bigger steps. Lean yet again.
    – Bookeater
    Jul 2, 2016 at 19:07
  • Right, there's another extreme to leave all checks to end-to-end tests which are long, flaky and hard to debug: googletesting.blogspot.com/2016/05/…. I prefer to leave as much as possible to unit tests which are short, reliable and easy to debug.
    – dzieciou
    Jul 2, 2016 at 21:20
  • I quite follow you... but the question points the other way.
    – Bookeater
    Jul 2, 2016 at 22:28
2

  • Write the smallest simplest tests possible to dry simple DRY SRP code.

  • Mock and Stub external services, most notable the database, so that unit tests run FAST.

  • Accept that good tests can take longer to write than application code.

  • Don't assume all tests remain for regression. prune aggressively once they've driven the code.

  • Make sure there are integrated / functional tests so you don't need to check them in unit tests.

  • Take care in descriptions and names in test, like all code it's read much more than it is written.
  • Use tags and labels to identify subsets of tests that you can run when doing tdd/bdd cycles.
  • Use tags and labels to identify slow running tests you can exclude when doing tdd/bdd cycles.
  • Use concise modern languages and frameworks such as Ruby-Rspec or Python.
  • Use a preloader that keeps the environment loaded and runs the test each time you save the file.
Improve this answer
4
  • "Use a preloader that keeps the environment loaded and runs the test each time you save the file." How that refers to unit tests? In unit tests you do not setup test environment.
    – dzieciou
    Jul 1, 2016 at 6:13
  • "Don't assume all tests remain for regression. prune aggressively once they've driven the code." How does that make writing unit tests quickier?
    – dzieciou
    Jul 1, 2016 at 6:14
  • 1. I use a preloader with unit tests that I am writing and it means they run in < 1 second instead of 30 seconds for the full environment load. The Ruby on Rails framework we use still requires some things to be loaded up. Having this efficiency and not waiting for the test to run with every little change makes the overall process of developing them faster for me as I may make 30 or 40 changes to a file, saving each time to see if they work.
    – Michael Durrant
    Jul 1, 2016 at 11:26
  • 2. Prune aggressively to reduce the number of tests that need to run pays off when you go to do more unit tests because the existing test code base is smaller, easier to understand, easier to maintain, easier to add more examples too. The more code that exists, the more you need to read and understand before writing additional tests. More relevant as the app and test code base grows over time.
    – Michael Durrant
    Jul 1, 2016 at 11:28

Your Answer

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

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