What are your tips and tricks for beginners writing tests?

Where should a beginner start when writing tests?

Comments

[Austin S. Hemmelgarn]

Some general tips that I see a lot of developers miss:

• Test to your defined API, and take the time to define things that your API consumers care about which are not explicitly defined. In essence, what matters is what you promise (via your API) to deliver, not the details that you don't call out. In short, test behavior, not implementation.
• Properly categorize your testing. Specifically, differentiate between unit tests, integration tests, end to end tests, and stress/performance tests. Each type is important, and each has a different purpose, make sure you know what type of test each test you write is because that helps you understand better both how to write the test, and what you're actually testing.
• Always leave stress/performance testing for last unless you have a clearly defined performance goal as an engineering requirement. Testing performance properly is seriously challenging, and often not very well supported, so unless you need these types of tests, they will usually end up being far more effort than they're worth.
• Don't mix test types within a test case. This is mostly a sanity tip. Any time you try to mix testing types inside a test case, it gets harder to figure out what exactly you're testing. Simple cases that test only one thing in one way are the easiest to understand and work with.
• Start with whatever type of testing your language/framework supports best, then cover the other types. Most languages or frameworks provide really good support for either unit testing or integration testing, and at best mediocre support for everything else. Always start with whatever type is best supported, as that will make writing the initial tests easy (and once you have those, it's easier to branch out into less well supported types of tests).
• Make sure to test your error handling. I see lots of people over-look this regularly, and it's actually really important (if you're not handling errors correctly all kinds of nasty things can happen).

[Márton Papp]

"Test Behavior, Not Implementation" - my tip is to write this down on a post-it note and stick it on somewhere.

[Michael Z]

Don't overthink "what to test". It will come naturally once you get the hang of it.

Start from the outside in with integration testing, at least when using a framework like Laravel or Adonis.js, they make this super easy.

[Mike]

Focus on the user flows for your application. If it's a web app, that's your web app visitors. If it's a command line interface you develop, it's the users of that CLI.

For anything web based, look at cypress.io. To start, there's no need to fully automate end-to-end tests for each pull request - that's something to work on later. Start with running your test suite against a staging or even production environment ever hour or 30 minutes, depending on how often you deploy. Then try to automate that process so that the tests run automatically after each deployment.

Write unit tests for complex functions. Don't test get and set functions on classes. A solid, fast-running test suite of end-to-end tests is more valuable in my opinion than 100% unit test coverage with lots of mocked parts of the overall system.

[Peter Witham]

I would say start simple, create tests for the simple things that make sense and then slowly expand over time to more complicated testing.

Diving in too fast and trying to achieve too much too soon will probably leave you wondering 'why bother with tests' until you realize that as a program grows, tests help keep everything straight.

[Pacharapol Withayasakpunt]

• Docstring, especially for Python, where there is doctest
  • I also recommend Pytest
• Test coverage, perhaps.