In fairness, I am unfamiliar with Magento, but if you're referring to the php e-commerce platform, I'd say that there are several things I'd look at in your position. First, I'd say if you're wondering if you're not using enough of a test driven approach, you probably aren't. I can also fairly fairly fanatic about it, more than is probably good for me.
I will start with the most degenerate of tests when I need to write a function, as in, write a test that tells me I return something other than 'null' from the function, and then start refactoring to add more specifics.
Second, I would look at the platform itself. Is it hindering me from writing good clean tests? If it's easier for me to run a debugger than it is to write a test, I'd feel like something was wrong somewhere.
The bottom line is that using a live debugger solves the same problem that REPL's solve, namely, tightening the feedback loop between the moment you write the code and the moment you know if it works. This is great for prototyping but it isn't sustainable for something intended for production. Production code will probably live much longer than you think it will and if you've been relying on anything other than automated tests to prove something behaves as expected, you're doing everyone, yourself included, a disservice.
Having said all that, using TDD is a choice, and as much as some of my colleagues may disagree with me, there are times it isn't appropriate. On the other hand I have come across very few instances outside of prototyping and investigation of production issues where the convenience of using a live debugger outweighed the advantages of writing a test. Also, if I have to use a debugger to solve it, I'm going to write a test to cover that exact situation because clearly it needed a test.
Agree about automated testing, but never thought of it as a substitute for a debugger. I'm sure I've used ipdb to debug new pytest unit tests. I'm bought in on automated testing, used to work in the semiconductor industry where mistakes are very expensive. Still some clients refuse to pay for them. At least so far...
I started to write a long-winded reply to this and realized I was rambling. Specifically, I don't think of a debugger as a substitute for testing, case in point is your comment about using a debugger to find unexpected issues with unit tests. I think debuggers serve a specific and related purpose to tests, which is to shorten the feedback loop used to validate the expected, specific behavior of code.
I do think that the way debuggers are typically used is as a substitute for testing.
I feel you on the semiconductor testing. Many (many) years ago I worked for a company called Pintail Technologies as the test automation guy. They company specialized in using statistical techniques to sample test chips and it was stunning how expensive a process testing chips was at a hardware level and how manufacturers would do anything to drop the cost.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In fairness, I am unfamiliar with Magento, but if you're referring to the php e-commerce platform, I'd say that there are several things I'd look at in your position. First, I'd say if you're wondering if you're not using enough of a test driven approach, you probably aren't. I can also fairly fairly fanatic about it, more than is probably good for me.
I will start with the most degenerate of tests when I need to write a function, as in, write a test that tells me I return something other than 'null' from the function, and then start refactoring to add more specifics.
Second, I would look at the platform itself. Is it hindering me from writing good clean tests? If it's easier for me to run a debugger than it is to write a test, I'd feel like something was wrong somewhere.
The bottom line is that using a live debugger solves the same problem that REPL's solve, namely, tightening the feedback loop between the moment you write the code and the moment you know if it works. This is great for prototyping but it isn't sustainable for something intended for production. Production code will probably live much longer than you think it will and if you've been relying on anything other than automated tests to prove something behaves as expected, you're doing everyone, yourself included, a disservice.
Having said all that, using TDD is a choice, and as much as some of my colleagues may disagree with me, there are times it isn't appropriate. On the other hand I have come across very few instances outside of prototyping and investigation of production issues where the convenience of using a live debugger outweighed the advantages of writing a test. Also, if I have to use a debugger to solve it, I'm going to write a test to cover that exact situation because clearly it needed a test.
Agree about automated testing, but never thought of it as a substitute for a debugger. I'm sure I've used ipdb to debug new pytest unit tests. I'm bought in on automated testing, used to work in the semiconductor industry where mistakes are very expensive. Still some clients refuse to pay for them. At least so far...
I started to write a long-winded reply to this and realized I was rambling. Specifically, I don't think of a debugger as a substitute for testing, case in point is your comment about using a debugger to find unexpected issues with unit tests. I think debuggers serve a specific and related purpose to tests, which is to shorten the feedback loop used to validate the expected, specific behavior of code.
I do think that the way debuggers are typically used is as a substitute for testing.
I feel you on the semiconductor testing. Many (many) years ago I worked for a company called Pintail Technologies as the test automation guy. They company specialized in using statistical techniques to sample test chips and it was stunning how expensive a process testing chips was at a hardware level and how manufacturers would do anything to drop the cost.