Code Quality Q&A and Videos

I'm an entry-level engineer who recently joined a team working in a new domain for me. Despite my best efforts, I find myself making mistakes in my code, such as forgetting edge cases, missing function calls, or mishandling character escaping (to quote a few recent ones). While these errors should ideally be caught during unit or integration testing, our team lacks a formal review process, leaving me solely responsible for testing my code before it gets merged. Consequently, bugs occasionally slip through, requiring post-deployment fixes. Although we're not a customer-facing team, I am afraid this puts a question on my reliability and erodes trust the team can place on me to write good code, that doesn't require iterations of fixes.

Could anyone offer advice on how I can better anticipate scenarios and prevent bugs from being introduced? I'm also unsure whether my challenges stem from a lack of technical skills or effective communication. How can I ensure I'm asking the right questions and considering all relevant factors before writing code?

Any insights or suggestions would be greatly appreciated.

I'm currently working through a task where I have to write unit tests. These unit tests in theory should test out the entirety of its class isolated from any other classes or function and effectively apply business logic on how these functions/methods are being called.

But where do I draw the line in regards to how much testing I'd need to run? Currently struggling with this PR because there's lots of lines of code (bad I know), but I do need to find out what a complete unit test looks like.

If you had to ask me, a complete unit test is where all the unit tests traverse through all code path and have both positive tests and negative tests being ran to show how the code should be used.

If there's some sort of guidance online, that would be helpful. Otherwise I'm mimicking what unit tests have been approved based on style and usage.