Are you for or against testing for beginners?

Coloured as I am from my personal experience, I learned to code using TDD. I found it incredibly effective. I tend to learn new languages by writing tests to see what the functions do. I remember 'testing' React functions to find out what the HTML being output would look like.

So I'd recommend it, but I'm sure there's more than one way to learn so don't worry about it too much.

I don't like this distinction that both post makes. Testing is necessary to deliver quality code. Whether you write your tests first and follow TDD strictly, or carefully plan the feature first and then write your tests, it does not matter. A feature needs to have tests in order for it to be added to the main branch, that is my philosophy.

We should, of course, not get carried away and strive for 100% code coverage, as code coverage is not a metric for how good your tests are. You can easily get to 100% coverage just by testing happy paths of your code.

Quality tests are the telltale sign of a good developer, and in order for everyone to get there, you need to write tests for every feature you develop. You will get better at it.

I think entry software engineers (not complete untrained beginners) joining as a professional should learn to test as early as possible. Knowing how to write tests demonstrate your ability to fully understand requirements. I often use test writing as an exercise for junior devs to ask the right questions.

But that said, I don't force them to write tests from day 1. I'm in the habit of letting juniors make mistakes first, and finding all the edge cases they didn't think of during code reviews, and showing them why they should start writing tests. They will also quickly find out that their peers who submit pull requests with tests gets their PR approved and shipped faster because reviewers can check quickly to see if all requirements are met and edge cases are covered.

What are we qualifying as a beginner? If they understand the basics of programming and have written a few personal projects then they are ready. Introducing testing before that point is just going to confuse them and distract from learning the fundamentals.

You need to be comfortable enough with a language to think about it in the abstract way required to write tests. If you can't write a function how can you be expected to test one? If you can't understand what would break a function when it is used or composed you can't understand how to test for that behavior. If you haven't written a few projects yet then you are going to drown in tests (many of which will change or be added / removed along the way) before learning how to plan and build one.

I think the best introduction to testing is through algorithm challenges. That will teach you how the "input expect output" flow works. From there you can apply those fundamental testing principles to real project code and continue developing your testing process.

edit: I wanted to respond before reading their articles to remove bias. After reading both I don't think they are contradicting each other. Both are saying the same thing (as what I said as well) which is that testing is valuable but only when you have enough fundamental understanding to learn it.

I personally wish I had learned testing long ago. I think a sweet spot for me would have been around 6 months of coding. In the time since I started testing I have learned and grown so much in my strategy and usage of testing libraries. That sort of knowledge can't be found in a video or an article but through testing many different applications and use cases.

They are both right. Testing gets a bad rap for being repetitive and people see testing like a user as an easy task new members can take on.

But that is very surface level testing. You want advanced testers who can break apart the system and generalize issues.

if you understand why we test, you will test. but enforcing some rigid rules on beginners is not so appealing!