In our org we are pretty ging ho about unit testing. Every bit of code needs to have near 100% unit tests. Which means right from design we need to make the code testable. Example never call APIs directly, call through interface wrappers etc. Make class members protected not private for testing. And a ton more. Factory implementation is given high importance as it makes it easy to implement tests. I have friends in other companies who work on similar tech as we do (windows kernel). They completely disagree with this strategy say unit tests are bull crap. Honestly to me unit tests make sense, u develop each class and test it, eventually the entire product is tested, where us the functional test approach of top down testing leaves gaps. Yes it is much easier to implement unit test for new products as I said, we need to consider it while designing, and legacy code won't lend much to it, but let's leave coDe age aside, and talk just about benefits and philosophy at this time. Wanted to get your views about this.
I think it is more about the code base you work with. If ur primary development is for legacy code and maintenance of it then you really won't agree to this right? Also if you work more with c than c++ then too i can see where the 'bull crap' attitude comes from.
It really depends on your architecture and specifics. I’ve worked in a codebase where individual unit tests were damn near useless due to the nature of the application (akka is guilty of this often) , integration and feature tests were more useful, especially as we were actively refactoring everything.
Please give an example of such an application
Legacy applications where theres too many dependencies, for one thing. Actor model, is another. There is no hard set rule -write the tests that you think will give you maximum assurance that the product works as expected. Having said that, I’ve seen some issues with DI and frameworks that use non deterministic resolution strategies for dependencies where automated testing testing simply cannot catch the problem because it’s random. Usually comes bundled with bad engineering habits.
Devs make up excuses not to write unit tests. Or they have an incorrect definition of unit tests and then write a few pseudo unit tests. These devs become dev managers, and they don't see the value of true unit tests...and so, we have a generation full of devs, which doesnt believe in the effectiveness of true unit testing. At the same time, they all pretend and deceive themselves that they know how to test their stuff.
Unit tests are extremely important, they’ve saved me huge amounts of time catching bugs dead in their tracks. A well written test suite has a lot of unit tests, a smaller number of integration tests, and a few end-to-end tests. It’s basically a pyramid. I am a firm believer in testing because it really helps clarify your thinking about what you expect your code to do, and helps to catch problems really early on before they turn into time consuming bugs. I used to never write tests, and as a result I wrote a lot of buggy code that was a pain to debug. Unit tests might seem like a waste of time, but in the end, a good test suite will be tremendously valuable.
Working in code that has a good test suite is more fun, because you find regressions quickly. In my experience this has been especially good for code near the bottom of the stack. But in some areas the bugs mostly strike during integration. The hard part isn't in getting units to work, it's in getting a bunch of units to play nice together. Passing unit test suites only help a little bit, because the contracts change rapidly in response to various factors for various units. Passing unit tests don't imply working systems. Keeping suites current ends up costing more and benefitting less. This has often been the case when working at the top of a tech stack. I'm not sure if the top/bottom thing is common or just the things happened to be in the products I've worked on. So just read that as an observation, not a prescription. Mostly, I'm a fan. I'd rather work in code that has good test suites. Mostly.
Great perspective on the stack example here, but I gotta ask... Yes integration is an issue and interface changes are a pain, and tend to break tests, all good points, however, if the inputs themselves are interfaces then it can be made more robust can't it? Example: Int foo(__in char *) Versus Int foo(__in Istring *) Where I string wraps and create abstraction around char*. This is ofcourse an overly simple example, but then such interfaces are more robust towards fuzzing attacks as well. And also keeps the dangerous code wrapped in the Istring object to a minimal.
I agree that loosely coupled, easily testable code is always better than having tightly coupled, barely-testable code. Being able to mock things out is always a win.
AMA
1h
266
I'm high as shit AMA
Software Engineering Career
15h
693
Amazon L5 to Google L4?
Health & Wellness
11h
986
How can I find success dating in NYC
India
Yesterday
2202
Slavery has REVERSED! the US is the slave!!! Check out this dude who pays a personal trainer in India
2024 Presidential Election
4h
616
Vote for Trump?
“I have friends in other companies who work on similar tech as we do (windows kernel). They completely disagree with this strategy say unit tests are bull crap.” You need to get new friends.