4

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?

1

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

  • 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 '16 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 '16 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 '16 at 21:20
  • I quite follow you... but the question points the other way. – Bookeater Jul 2 '16 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.
  • "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 '16 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 '16 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 '16 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 '16 at 11:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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