I would write tests but the project I am working on at work had no tests when I joined the point and is too big to go back and write them and my personal projects seem too small to benefit from the effort at the moment . My big issue with tests is "how do you ensure them test themselves are correct and 100% accurate. As tests written by humans with have errors and bug at some point. do we write tests for tests themselves ?"
how do you ensure them test themselves are correct and 100% accurate
If you mean how to avoid making false positives in test, of course tests like any other code should be peer-reviewed by your teammates. And most importantly, you can check the code coverage for your unit tests so that you know that the tests are actually covering your branches and statements of the code accurately.
As for dealing with codebase that has no tests, I feel you. I've been there before. What was tricky is actually splitting the code so that it's testable, between pure functions and side effects. That should be the first step even before writing any tests. Then, start increasing test coverage gradually, starting with helpers/small pure function modules down to components. FWIW my experience is from a frontend codebase, but I hope you get the gist of it.
Small project, prototypes, yes maybe your argument about not having tests is valid for these. But, as soon as those small projects are used by someone else (maybe you made it open-source), and/or has the possibility to get complex, then that's where tests can be beneficial.
Writing (automated) tests starts with one small step - the desire to write them. If you can't state precisely what your code is mesnt to do (by writing a test) how can you even start coding? Once you have written a few, you will start to notice that your features get bounced by QA less often - and a 'virtuous cycle' starts.
Writing tests is a habit, which takes practice. You could try practicing on your personal projects.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I would write tests but the project I am working on at work had no tests when I joined the point and is too big to go back and write them and my personal projects seem too small to benefit from the effort at the moment . My big issue with tests is "how do you ensure them test themselves are correct and 100% accurate. As tests written by humans with have errors and bug at some point. do we write tests for tests themselves ?"
If you mean how to avoid making false positives in test, of course tests like any other code should be peer-reviewed by your teammates. And most importantly, you can check the code coverage for your unit tests so that you know that the tests are actually covering your branches and statements of the code accurately.
As for dealing with codebase that has no tests, I feel you. I've been there before. What was tricky is actually splitting the code so that it's testable, between pure functions and side effects. That should be the first step even before writing any tests. Then, start increasing test coverage gradually, starting with helpers/small pure function modules down to components. FWIW my experience is from a frontend codebase, but I hope you get the gist of it.
Small project, prototypes, yes maybe your argument about not having tests is valid for these. But, as soon as those small projects are used by someone else (maybe you made it open-source), and/or has the possibility to get complex, then that's where tests can be beneficial.
Writing (automated) tests starts with one small step - the desire to write them. If you can't state precisely what your code is mesnt to do (by writing a test) how can you even start coding? Once you have written a few, you will start to notice that your features get bounced by QA less often - and a 'virtuous cycle' starts.
Writing tests is a habit, which takes practice. You could try practicing on your personal projects.