I’ve always thought it weird that the intro CS course I took at my university didn’t even mention unit testing. After being in the industry for several years, it’s become obvious that the majority of what I do is just writing tests.
If you wanted to introduce every industry best practice in an intro course you’d never get to the actual programming.
It would be good to have a 1 credit course(one hour a week) where you learn industry best practices like version control, testing and stuff like that. But it definitely shouldn’t be at the start.
I teachers were using automated tests instead of printf in their intro courses, it would be so much better. I don’t think that introducing all the various kind of tests is usefull, but just showing the concept of automated tests instead of manual ones would be a huge step forward.
The thing is the way they motivate new students to learn programming is by having them write programs that do something. Making a test green isn’t as motivating as visually seeing the output of your work, and test fixtures can be complex to set up depending on the language. I mean students don’t learn how to factor their code into methods until later into such a course, they’re learning if statements and for loops and basic programming constructs. Don’t you think having to explain setting up test fixtures and dependency inversion is a bit too much for people at that level?
Honestly, that is weird. I wouldn’t expect an intro course to go into a lot of depth on testing or even necessarily show how to use a test framework, but I’d expect them to at least have “printf style” unit tests.
But lol, yeah, tests usually take far longer to write than the actual change I made. A one line change might need a hundred lines of test code. And if you’re testing something that doesn’t already have a similar test that you can start off from, programming the test setup can sometimes take some time. Depends a lot on what your code does, but sometimes you have to setup a whole fake database and a hierarchy of resources with a mixture of real objects with stubs.
And then there’s me, who almost never writes unit tests 😬
(With strong typing I can minimize explicit tests, and I like to iterate fast, but I guess it really depends on what you’re developing, backend in production that is not allowed to fail, is probably something different than a game)
Strong typing doesn’t prevent the need for tests. It can certainly catch some issues (and I don’t like dynamically typed languages as a result), but there’s no replacement for unit testing. So much refactoring is only safe because of rigorous test coverage. I can’t begin to tell you how many times a “safe” refactoring actually broke something and it was only thanks to unit tests that I found it.
If code is doing anything non-trivial, tests are pretty vital for ensuring it works as intended (and for ensuring you don’t write too much code before you realize something doesn’t work). Sure, you can manually test, but often manual testing can have a hard time testing edge cases. And manual testing won’t help you prevent regressions, which is usually the biggest reason to write unit tests. If you have a big, complicated system worked on by more than one person, tests can be critical for ensuring other people (who often have no idea how your code works) don’t break your test. Plus your own future changes.
I’ve always thought it weird that the intro CS course I took at my university didn’t even mention unit testing. After being in the industry for several years, it’s become obvious that the majority of what I do is just writing tests.
If you wanted to introduce every industry best practice in an intro course you’d never get to the actual programming.
It would be good to have a 1 credit course(one hour a week) where you learn industry best practices like version control, testing and stuff like that. But it definitely shouldn’t be at the start.
I teachers were using automated tests instead of printf in their intro courses, it would be so much better. I don’t think that introducing all the various kind of tests is usefull, but just showing the concept of automated tests instead of manual ones would be a huge step forward.
The thing is the way they motivate new students to learn programming is by having them write programs that do something. Making a test green isn’t as motivating as visually seeing the output of your work, and test fixtures can be complex to set up depending on the language. I mean students don’t learn how to factor their code into methods until later into such a course, they’re learning if statements and for loops and basic programming constructs. Don’t you think having to explain setting up test fixtures and dependency inversion is a bit too much for people at that level?
Honestly, that is weird. I wouldn’t expect an intro course to go into a lot of depth on testing or even necessarily show how to use a test framework, but I’d expect them to at least have “printf style” unit tests.
But lol, yeah, tests usually take far longer to write than the actual change I made. A one line change might need a hundred lines of test code. And if you’re testing something that doesn’t already have a similar test that you can start off from, programming the test setup can sometimes take some time. Depends a lot on what your code does, but sometimes you have to setup a whole fake database and a hierarchy of resources with a mixture of real objects with stubs.
And then there’s me, who almost never writes unit tests 😬
(With strong typing I can minimize explicit tests, and I like to iterate fast, but I guess it really depends on what you’re developing, backend in production that is not allowed to fail, is probably something different than a game)
Strong typing doesn’t prevent the need for tests. It can certainly catch some issues (and I don’t like dynamically typed languages as a result), but there’s no replacement for unit testing. So much refactoring is only safe because of rigorous test coverage. I can’t begin to tell you how many times a “safe” refactoring actually broke something and it was only thanks to unit tests that I found it.
If code is doing anything non-trivial, tests are pretty vital for ensuring it works as intended (and for ensuring you don’t write too much code before you realize something doesn’t work). Sure, you can manually test, but often manual testing can have a hard time testing edge cases. And manual testing won’t help you prevent regressions, which is usually the biggest reason to write unit tests. If you have a big, complicated system worked on by more than one person, tests can be critical for ensuring other people (who often have no idea how your code works) don’t break your test. Plus your own future changes.