If you're a developer tirelessly pushing out new changes, only to be dragged back by errors in your past work, this post is incredibly relevant f...
For further actions, you may consider blocking this person and/or reporting abuse
This part. 👏
🙏🏼 Jayant
"The simplest way to ensure your code works as expected is by adding unit tests."
I'd argue it's functional tests. They're less brittle, and more likely to provide confidence that the application does what it's supposed to do the way it's supposed to do it.
Unit tests make your codebase probably 10x larger or more. That's a lot more maintenance.
The argument is that unit tests allow you to make changes confidently because they will catch regression faults. So they would increase development speed. But the unavoidable counterargument is that with so much more code to maintain... code that is directly tied to the lowest level of code, binding to every interface, every type, every property creates so much inertia, how will it balance out?
And if you are really making big changes you may end up discarding a whole lot of unit tests as things get reworked. In which case, you ended up doing work that had no real longevity. Bad investment.
The balance I recommend is unit tests for hard fought, intricate internal business logic you want to lock in forever, and functional tests for everything else.
They're both really functional tests but unit tests can get you more solid testing on certain things, while being easier to write.
I wrote an emulator... I created unit tests for the CPU, and some hardware simulations. These are forever code but I want to ensure they stay working now and forever. Great investment. And they're fast and short... I can test every instruction at a very granular level without having the coding and execution overhead of other layers.
Outside the core of the emulation I expect a lot of churn. I want to detect memory leaks, 2nd level issues across modules, performance issues, basically stuff that unit tests won't see anyway. That stuff wants a functional regression suite.
Code that doesn't do something functional for a user and never prevents a bug is cost with no business benefit.
If your budgets and time are infinite, write all the units tests you want.
I think both.
Functional tests ensure the product functions as expected. Unit tests (TDD-style) ensures the code complies with basic correctness.
That's a great take.
Love the balanced perspective on this, @jhoger!
Divide up your unit tests into two separate groups, development and release.
If you refactor your code and your release tests break, it's a problem.
If you refactor your code and your development tests break, it might be safe to change the tests instead of the code.
No... you double your work and you repeat yourself.
You just need to refactor the tests before the code.
Thank you for sharing 😊
I would label "4. Always Answer with a Link" as a broader concept "always plan for being unnecessary to the project". It applies to more categories than the one you mentioned.
Keep up the good work !
Thanks for the input @bcouetil! I agree to your point.
The advice of sharing a link always just makes it more actionable :)
I would add
I just love contracts:
insertprocedure that thekeygiven to the procedure now must be present in the map and the corresponding value must be thevaluegiven to the procedure. This is something that must be true, whatever the implementation you choose, because it is part of the "abstract nature" of an associative map.I feel compelled to point out to any newer devs that this sentence "Shipping code without testing all the edge cases is like a spray and pray strategy" is nonsense. It is literally impossible to test every possible edge case in an application with even a tiny amount of complexity. Your applications WILL fail, you should test the most complex/important/used parts of an application. And especially where those labels overlap. 100% code coverage is NOT a codebase with no errors.
Thanks for the candid comment @lovetrax! While it is difficult to write tests for every possible edge case but it is indeed possible to define a scope relevant to the business/product and test for those cases. That will make the code robust for the defined scope.
When things out of your scope start to break, you can take an educated call to include it or ignore it 😊
Great article. In theory, I agree with 99% of what was said. Unfortunately, this is only in theory. There are many companies where there simply is no time to do all of this. There are companies where results and getting the latest features out on a hard deadline is the top priority and as soon as that is done, there is another feature that is expected to be done ASAP as there is a hard deadline and so the cycle continues, this is very common for startups that have investors and a board to keep happy.
Trying to convince board members who are not tech-savvy that 50% to 70% (a personal guestimate) of development time will be tests and documentation is going to be a hard sell.
Great point @baasmurdo! That's a change that tech leaders have to drive with other stakeholders not by hiding but by educating.
In one of my EM stints, I literally did a tech process onboarding for non tech joiners so that they understand what our estimates meant and what all a developer does apart from just writing code.
interesting read Dhruv!
Thanks Shivam!
This is a really good read. Lately I have been a victim to reacting to bugs 😅. I will start asking those 3 questions on everything I build from now on. It seems like a really good way to avoid bugs early on and save those tens of hours of debugging. Thanks!! 😊
Thank you for sharing such valuable insights!
Awesome @vipindevelops!
I like it!
I would also add, always ask a question with a link
Interesting take @natisayada!
Great article
Thanks @anilsonix! Glad you liked it
Awesome post, thanks!
Wonderful article with very practical tips and how-tos! Thanks a lot for posting and sharing!
In class today, my classmate asked if working with fellow developers is typically characterized by a very cooperative and supportive atmosphere.
I guess the word spread already. "No one can do it all alone." We are all in this together.