# Write Tests

> Last updated: 2013-05-17

Another blog post based on my [Testing Anti-Patterns](/../talks/mwrc_13.html) Talk

The most common testing anti-pattern seems to be not writing them to
begin with. In my experience not writing tests is rarely a technical
problem, instead its usually a people problem. People problems tend to
be hard to solve but spending the time to fix them is worth it.

### Not Writing Tests

People have a lot of excuses for not writing tests. Some of my
favorites:

  * I don't know how to write tests
  * I don't have enough time to write tests. This project is already behind schedule.
  * I want to write tests but my boss won't let me. 

Let me go through these one by one.

#### I don't know how to write tests
Its okay if you don't know how to write tests. Today is a great day to
learn. Every language I've used has a test framework. Find one for
your language and start reading the documentation that's usually
enough to get you started. If you need more help there are lots of
blogs, talks, books on automated testing that can teach you basic
concepts and give you ideas for structuring your tests. 

#### I don't have enough time to write tests.

This quote from DocOnDev summarize exactly why not having enough time
to write tests is absurd. 

![Twitter quote](/img/not_writing_tests.png)

Your tests are your safety net. They help ensure your code does what
you want. They make sure you aren't breaking existing code. And if you
do TDD/BDD writing your tests can help you design your algorithms and
focus on one problem at a time. When you are short on time is exactly
when you need your tests to help you out.

#### I want to write tests but my boss won't let me. 

I've been in this situation before and it is tough. I've found that you can
often chip away at these type of objections piece by piece. Start with
a single test in a place with clear benefit. For example, write a test
to ensure a production bug is truly fixed or a test against a commonly
broken user scenario. Enlist the help of your QA team (if you have
one) to advocate for unit tests. Spend downtime back filling tests
against important features. As your boss sees the benefit that tests
offer they may come around. 

So go forth and write tests.