Writing tests for your software is an established practice in most development environments nowadays. It also makes a lot of sense. Code that is subject to changes and changes will need some sort of plan for knowing it still does what is it actually expected to do. Tests do that for you.
Writing tests for your software is also a vessel for excessive nit-picking and countless discussions about the “one true way”. Testing snobism is a real thing. The multitude of approaches, even philosophies and the abundance of tooling makes the concept inaccessible for beginners, occasional programmers and self-taught makers.
Fact is, many people - including myself - will still start their programming career driven by the simple requirement that they need something that is not there yet. So they build it, they iterate on it. They shouldn’t have to setup a fully automated test suite for everything when they just started.
I think the fundamentals of testing and writing testable code can be taught without relying on test runners, frameworks, assertions libraries and whatever advanced concepts are out there. Those can be introduced on large codebases that will be worked on by a team. But when just starting, keep it simple.