In college, I always heard about unit testing and how important it was, but it wasn't taught.
In my first job as a software engineer, we had an extremely Legacy system and the company didn't want to "waste" time on going back and making tests for things.
At my second one, a startup, I constantly asked for it (since I honestly didn't know what it actually was, I was afraid to just.... Do it), and was told to leave it on the back burner until we got the product out.
At both jobs, I know that we constantly ran into the same bugs, that would've easily gotten caught. I knew there was a solution, but didn't feel I had the permission or knowledge to make it happen.
Recently I've been working on my own project and wanted to tackle the daunting task of Unit Tests. It is extremely easy to get lost in the weeds. You start by seeing a tutorial with the most basic of tests, like assert.equals(1+1, 2), and you think you can handle it all. And then you do a little more research and see people talking about mocks, spies, stubs, test runners vs test frameworks. It's so easy to get overwhelmed and want to give up.
Truly, starting simple is extremely important. There are SO many things that you can sufficiently test with a basic assert.equals(myVar, 5). Let all of the bells and whistles come as they're needed.
I'm starting to develop a few tools for my company and I'm getting into it and that's true that's it's so easy to get lost and it's better to start small.
But I would say it is the same as everything in programming.
After a few years not following what's new in Javascript, I'm learning all about Node.js, Express, Vue, React, Graphql, Apollo etc ...
And that's only related to javascript!
I bet this is a common story. I had the same exact thing happen to me. Jobs where tests weren't of any importance so I just never learned. I had to force myself and be the example for the team.
Same story here with at the end not being able to use TDD.
I used to develop naturally close to the TDD way. I would create a function, test every scenario manually and once it worked, move on to the next bits of code.
When TDD became popular and I heard of it (many years ago), I was super excited and wanted to try that, only to be told we could not do that.
At the time, processes and technologies were strictly controlled in the industry I worked in (finance).
I gave up pushing for it.
Then, a few years later, I became tech support in a different company and industry and I saw they were using unit tests so at least I can say I've read test units, even if I've never created them.
Sadly common story. I tried for several years to unsuccessfully convince the leadership at a consulting agency that they didn't need to sell unit tests separately, but they were a core feature of the development itself and that we should always write it them for all our code.
But no, to this day (10+ years after I started, 5 years after I left) that company still considers unit tests to be an extra, something people do at other places.
Gladly at the next place there were some unit tests, but still at a poor level. People didn't think of them at all, most of them were actually not unit tests but massively slow monsters. They pretended their SOLID principles were all that were needed to make code easily testable, and .. it wasn't. More like the opposite in many cases.
Nowadays there's little I do without unit tests, and require them in all projects I'm working with. I consider it more like you don't really know your stuff works before you can prove it with unit tests. You don't always need a lot of them, but you still need to have them.
The recent trends in unit testing tools and methods getting better are just amazing, with Python the mock library is simply incredible and most dbs and such come with mocking libraries too, and things like snapshot testing are making so many things easier to test.
Unfortunately still there are still several common areas that are annoyingly difficult to test, you'd think that by now websites were super easy to test but often this is not the case. Also in the gamedev world you will find automated tests to be almost non-existent, but the gamedev world tends to move quite slowly overall so it's not that surprising.
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.
In college, I always heard about unit testing and how important it was, but it wasn't taught.
In my first job as a software engineer, we had an extremely Legacy system and the company didn't want to "waste" time on going back and making tests for things.
At my second one, a startup, I constantly asked for it (since I honestly didn't know what it actually was, I was afraid to just.... Do it), and was told to leave it on the back burner until we got the product out.
At both jobs, I know that we constantly ran into the same bugs, that would've easily gotten caught. I knew there was a solution, but didn't feel I had the permission or knowledge to make it happen.
Recently I've been working on my own project and wanted to tackle the daunting task of Unit Tests. It is extremely easy to get lost in the weeds. You start by seeing a tutorial with the most basic of tests, like
assert.equals(1+1, 2), and you think you can handle it all. And then you do a little more research and see people talking about mocks, spies, stubs, test runners vs test frameworks. It's so easy to get overwhelmed and want to give up.Truly, starting simple is extremely important. There are SO many things that you can sufficiently test with a basic
assert.equals(myVar, 5). Let all of the bells and whistles come as they're needed.I'm starting to develop a few tools for my company and I'm getting into it and that's true that's it's so easy to get lost and it's better to start small.
But I would say it is the same as everything in programming.
After a few years not following what's new in Javascript, I'm learning all about Node.js, Express, Vue, React, Graphql, Apollo etc ...
And that's only related to javascript!
I bet this is a common story. I had the same exact thing happen to me. Jobs where tests weren't of any importance so I just never learned. I had to force myself and be the example for the team.
Same story here with at the end not being able to use TDD.
I used to develop naturally close to the TDD way. I would create a function, test every scenario manually and once it worked, move on to the next bits of code.
When TDD became popular and I heard of it (many years ago), I was super excited and wanted to try that, only to be told we could not do that.
At the time, processes and technologies were strictly controlled in the industry I worked in (finance).
I gave up pushing for it.
Then, a few years later, I became tech support in a different company and industry and I saw they were using unit tests so at least I can say I've read test units, even if I've never created them.
Sadly common story. I tried for several years to unsuccessfully convince the leadership at a consulting agency that they didn't need to sell unit tests separately, but they were a core feature of the development itself and that we should always write it them for all our code.
But no, to this day (10+ years after I started, 5 years after I left) that company still considers unit tests to be an extra, something people do at other places.
Gladly at the next place there were some unit tests, but still at a poor level. People didn't think of them at all, most of them were actually not unit tests but massively slow monsters. They pretended their SOLID principles were all that were needed to make code easily testable, and .. it wasn't. More like the opposite in many cases.
Nowadays there's little I do without unit tests, and require them in all projects I'm working with. I consider it more like you don't really know your stuff works before you can prove it with unit tests. You don't always need a lot of them, but you still need to have them.
The recent trends in unit testing tools and methods getting better are just amazing, with Python the
mocklibrary is simply incredible and most dbs and such come with mocking libraries too, and things like snapshot testing are making so many things easier to test.Unfortunately still there are still several common areas that are annoyingly difficult to test, you'd think that by now websites were super easy to test but often this is not the case. Also in the gamedev world you will find automated tests to be almost non-existent, but the gamedev world tends to move quite slowly overall so it's not that surprising.