Hooray for testing!
As time goes on you'll begin to uncover that writing tests is a whole different skillset. Enjoy getting better at it!
As you continue to test, here are a few experiments to consider:
1) Mocking - Used to isolate pieces of code from one another. How would you write this test without mocking? What would the smallest, "Unit" of code that you can test be? What might that tell you about your coupling?
2) Write your test first. Write a test that expresses the wish of your code. Watch it fail, then work to get it to pass. How does your test/implementation code look compared to the other way?
yeah, I read about the test-driven approach, Sounds cool. But I don't feel that many people are using it
Number of people using is an irrelevant metric. What matters is when (what conditions) you should use it.
If you design your implementation before writing your code (which most any skilled engineer can and should do), TDD is just codification of the design. If you skip that step, then you can't do TDD.
If the number of bugs is irrelevant to the release of the product and it's adoption (ex: internal application with a captive user base), TDD adds cost that may not be worth it.
If you have no/fluctuating requirements and the timeline won't allow for it, it's unlikely you can do TDD (lazy enterprise approach).
That said, even if your team isn't bought into it, that doesn't preclude you from adopting it as a rigorous process that results in you delivering a better product with lower failure rates.
I like trying out approaches just for the sake of it, at the least i will try it out in the future. Will definitely share my experience too. Thanks @asparallel
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.