Data wrangler, software engineer, systems programmer, cyclist. Unix (mostly Solaris) for aeons. I talk C, Python, SQL, Performance, Java, Kafka and Makefiles.
Location
Brisbane, Australia
Education
BA (Mathematics, Modern History), University of Queensland
Unit testing is your insurance policy - that (a) what you've written does what you say it should do, and (b) that when you or somebody has to make a change, It Can Be Confirmed That You Haven't Broken Things.
How can you prove that it works if you haven't got a test for it?
I totally agree with you. But I know a lot of people who would rather debug during development and/or if something is broken than writing a test. Specially when one is maintaining legacy code which was not built with unit tests in mind.
Data wrangler, software engineer, systems programmer, cyclist. Unix (mostly Solaris) for aeons. I talk C, Python, SQL, Performance, Java, Kafka and Makefiles.
Location
Brisbane, Australia
Education
BA (Mathematics, Modern History), University of Queensland
That's an opportunity to bring things (and people) in from the cold. It's a mindset shift, but one which makes us better programmers/developers/engineers. That in turn means that we've got a "layer 8" problem - and that's where our person-to-person abilities need to be brought to bare.
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.
Unit testing is your insurance policy - that (a) what you've written does what you say it should do, and (b) that when you or somebody has to make a change, It Can Be Confirmed That You Haven't Broken Things.
How can you prove that it works if you haven't got a test for it?
I totally agree with you. But I know a lot of people who would rather debug during development and/or if something is broken than writing a test. Specially when one is maintaining legacy code which was not built with unit tests in mind.
That's an opportunity to bring things (and people) in from the cold. It's a mindset shift, but one which makes us better programmers/developers/engineers. That in turn means that we've got a "layer 8" problem - and that's where our person-to-person abilities need to be brought to bare.