Testing as a new programmer

Lots of new programmers tell me that they don’t test, which is understandable. I didn’t start my programming career testing. It wasn’t a ‘thing’ at all when I was programming. Now that I have been testing, I find testing is a beautiful tool, but all new programmers just don’t learn it, even with all the great tools, resources, and support. Common sentiment I hear is they just find testing stupid, don’t know what to test, don’t have energy to learn testing, do not understanding tests are not for them, and don’t know the first rule of Test Driven Development (TDD).

Tests are silly

Testing definitely feels stupid when starting learning to program. As one is learning to program, they are learning to control a computer with code. The code being written is: 1+1, kind of pedatric. When tests are added in, the tests start to be: 1+1==2? When seeing this, the code definitely looks & feels stupid, but it’s ok. The code is rudimentary, the test is even more pedanric. It’s part of learning. Everybody needs to walk before they can run. The great thing about tests for learning is there is twice as much code being written than without tests. Now the code being written is: 1+1 and the test: 1+1==2, which is more code (remember, tests are code too!) By writing more code, you’re learning faster. There is so much code to write, and this is the right kind of code to be writing lots of.

What should be tested?!

When testing does get started, the next issue is: there are so many things to test! What should be tested?? How should the code be tested? Should 1+1 be tested? The result of 1+1 will always be 2, why test it?? Every child knows this. It is good to test simple things just so you know your test framework is working. I test truthiness as a quick way to validate my test framework is setup properly. There are a lot of components to a program, connecting a test framework is tricky. Make it easy by testing easy stuff. There’s no worst feeling in the world than writing a bunch of tests and realizing things are not connected.

Testing external services

Web applications have a huge number of dependencies. When beginning programming, programs can just be external services connections. Do those have to be tested as well? It’s good to test external services just to ensure correctness, so write out basic tests for services. Almost every service will have a ‘test’ account you can access. Hit those directly so you can keep moving on with your code. It will be slow, but get the tests right first. Don’t worry too much about having super efficient tests at the beginning. There will be time later to improve test efficiency. With external services, access them directly until you get to the ‘refactor’ part of testing.

“Testing slows me down”

“There is so much to learn, do, and master already, tests just slow me down.” Welcome to the club! There is always something new to learn, even you have been programming for a long time. Trust me, the learning does not stop. Learning testing will feel like they are slowing you down at the beginning, but the real value of tests come later when the system is large and complex. I feel tests are almost your custom tool you built for your program. It keeps the system clear with small tests describing individual parts of your system. Tests also help debug a problem because you can isolate which code is causing the bug. Testing is another thing to learn, but its rewards are much greater later.

Testing attitude

New programmers have the wrong attitude towards testing: they make the mistake of believing tests are for them at that moment. The moment tests are written, you understand what you are doing. The moment you move on (to new feature, new project, new job, new life, …) your understanding decreases dramatically, requirements change, another programmer added code to the project. So many things can happen to your code. Tests are there for future you, another developer, the maintainer, and whoever needs to debug your code. Tests are not there for you now, it’s for the future.

The first rule of TDD…

Understand the first rule of TDD:

“You are not allowed to write any production code unless it is to make a failing unit test pass.”

The emphasis here is: production code. Is the code you are using to ‘learn’ will be put into production? Is the code paid by someone to use? Not every single line of your code will have to be tested from here on out. Code that you ‘play’ with, try stuff out with, use to figure out what you want to do next, stuff that NEVER goes into production… that doesn’t need tests, because the code does not go into production.

Be brave and keep testing!

Programming is tough, but tests are there to help, not make things harder. Remember, production code need tests, not every single line of code you write. Tests are not for you right now as a programmer, but for a future programmer that has to interact with your code. The sooner you learn testing, the better your code becomes. Test external services directly at the beginning. Testing with super simple things like 1+1=2 is fine, it can help make sure your system is setup and you can delete those tests as your code improves.