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.
Want to see the real deal?
More inside scoop? View in App
More inside scoop? View in App
blind
SUPPORT
FOLLOW US
DOWNLOAD THE APP:
FOLLOWING
Industries
Job Groups
- Software Engineering
- Product Management
- Information Technology
- Data Science & Analytics
- Management Consulting
- Hardware Engineering
- Design
- Sales
- Security
- Investment Banking & Sell Side
- Marketing
- Private Equity & Buy Side
- Corporate Finance
- Supply Chain
- Business Development
- Human Resources
- Operations
- Legal
- Admin
- Customer Service
- Communications
Return to Office
Work From Home
COVID-19
Layoffs
Investments & Money
Work Visa
Housing
Referrals
Job Openings
Startups
Office Life
Mental Health
HR Issues
Blockchain & Crypto
Fitness & Nutrition
Travel
Health Care & Insurance
Tax
Hobbies & Entertainment
Working Parents
Food & Dining
IPO
Side Jobs
Show more
SUPPORT
FOLLOW US
DOWNLOAD THE APP:
comments
You need to get new friends.
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.
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.
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.
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.