One advantage of unit tests you've missed out is that they are fast. Both fast to write and fast to run. This means you can have a lot of coverage with minimal overheads.
I would say that is much more of an advantage than Seeing a sea of green as the tests pass. What purpose is seeing a sea of green if there is no trust in the tests you've written?
Are they really? I can se how this might apply to the early stages of a project with enough discipline and experience also thrown into the mix. But what about legacy/existing code. Sprinkling some small changes into a method wo UTs would result in a couple of hours of mocking, stubbing and dummy-ing.
I would agree that retroactively trying to add unit tests to code that you're not familiar with / didn't write can be a little more tricky but not impossible. This isn't unique to unit tests though as the same applies to integration and E2E.
In saying that, if you're working with legacy code, I think it is fair to assume that you're still adding code / features / bug fixes. It is at this time when you can add those tests (unit or otherwise) as you have more familiarity with the code. This would be akin to following the boy scout rule.
Hi, I normally contract in MSBI, Oracle, .Net/.Net Core, focusing on a property platform at the moment. Have also been working hard on upgrading my limited company website too.
I am coming from it more that if we write applications which are data focused - integration tests are better. A great example could be coding in a portfolio swap for a known test case, if this is stubbed that stub can become stale quickly. In this example, I may store the stub as a json file (deserialised IList). This allows testers and analysts to put in their own test cases. I wrote about this here (kind of) dev.to/zakwillis/novel-tips-on-uni...
I think your point is valid, imagine if there is legacy code. Yes, I would probably setup up a separate unit test project as a means of understanding the code. However, where legacy systems exist, they are only understood by their outputs - which again leans towards integration testing, despite how slow the process may be compared to unit testing.
Hi, I normally contract in MSBI, Oracle, .Net/.Net Core, focusing on a property platform at the moment. Have also been working hard on upgrading my limited company website too.
I know that what you say sounds fine - completely, there is faster feedback on unit tests - no doubt! As said, am not against them - when people focus on test coverage - it is a false dawn, unattainable.
Calculations and logic are perfect reasons for adding unit tests, but that most "proof is in the pudding". For example, deploying to a test environment with sufficient test coverage will reveal more than esoteric unit tests.
Also agree on your point re sea of green and no trust :)
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.
One advantage of unit tests you've missed out is that they are fast. Both fast to write and fast to run. This means you can have a lot of coverage with minimal overheads.
I would say that is much more of an advantage than
Seeing a sea of green as the tests pass
. What purpose is seeing a sea of green if there is no trust in the tests you've written?Are they really? I can se how this might apply to the early stages of a project with enough discipline and experience also thrown into the mix. But what about legacy/existing code. Sprinkling some small changes into a method wo UTs would result in a couple of hours of mocking, stubbing and dummy-ing.
I would agree that retroactively trying to add unit tests to code that you're not familiar with / didn't write can be a little more tricky but not impossible. This isn't unique to unit tests though as the same applies to integration and E2E.
In saying that, if you're working with legacy code, I think it is fair to assume that you're still adding code / features / bug fixes. It is at this time when you can add those tests (unit or otherwise) as you have more familiarity with the code. This would be akin to following the boy scout rule.
I am coming from it more that if we write applications which are data focused - integration tests are better. A great example could be coding in a portfolio swap for a known test case, if this is stubbed that stub can become stale quickly. In this example, I may store the stub as a json file (deserialised IList). This allows testers and analysts to put in their own test cases. I wrote about this here (kind of) dev.to/zakwillis/novel-tips-on-uni...
I think your point is valid, imagine if there is legacy code. Yes, I would probably setup up a separate unit test project as a means of understanding the code. However, where legacy systems exist, they are only understood by their outputs - which again leans towards integration testing, despite how slow the process may be compared to unit testing.
I know that what you say sounds fine - completely, there is faster feedback on unit tests - no doubt! As said, am not against them - when people focus on test coverage - it is a false dawn, unattainable.
Calculations and logic are perfect reasons for adding unit tests, but that most "proof is in the pudding". For example, deploying to a test environment with sufficient test coverage will reveal more than esoteric unit tests.
Also agree on your point re sea of green and no trust :)