McGruff wrote:I really don't think it's fair to make statements about testing in OOP unless you've had some experience using it - please correct me if I'm wrong.
You are extremely wrong.
Here's my background info. I've coded in OOP for about 7 years. I started my work in OOP with C++, and when I came to PHP, I found similar references several years ago.
McGruff wrote:Do you have a favourite testing tool? What are your strategies for regression testing? Continuous integration? Refactoring? Have you tried test driven design?
Most of my day-job php programming is done using OOP and unit testing. I use
SimpleTest for most of my tests, as I find it to be rather good at getting out of my way and letting me get to work (grin).
Regression testing I personally do at development milestones. I'll target an improvement, work towards it, test it, and then when I've reached it, I generally run a test suite against affected portions. If its unclear what portions might have been affected (rare), I'll do a full suite run.
Because I'm lucky enough to have discrete and well-defined project goals (since I generally set them), I don't rely as much on continuous integration. After reaching a stable build, I focus on changes from there, and avoid massive rewrites and refactoring.
I actually find refactoring to be a bit of a buzzword/fad. I do reviews of my code regularly, and by many definitions, you could call much of what I do refactoring, but honestly, its just overhyped as a development goal.
I think the important thing to mention here is that you are focusing on my knowledge, and my history, and avoiding the discussion of the issue. Thats called a straw man argument, and its a bad habit in online discussions. As you can see, I'm fully qualified in every sense of the word to comment on both sides of the debate.
Personally, I don't care about the background of the people here. Even a longtime master can learn from the fresh perspective of a beginner, so I welcome the discussion without worrying about the person.
McGruff wrote:Buddha443556 mentioned that you can test data structures. I can't quite see how this is really giving you the same grip on the app. Without encapsulation, data and behaviour isn't bundled together in neat little parcels.
Thats exactly right: Data and behavior isn't bundled together tightly. That doesn't neccesarily result in less control. OOP and procedural approach application development from opposite directions. OOP looks at the program in terms of objects and behaviors. Starting with broad categories and working down to discrete patterns of code.
Procedural looks at applications in terms of data (a concept that is different from objects), and functional goals. Some describe OOP as top-down, and Procedural as bottom-up, but I think both oversimplify things. At its heart, I think the best comparison I can make is that procedural is more focused on what the program DOES, and OOP is more focused on HOW.
McGruff wrote:In OOP, you can conveniently stub out whole swathes of code in a test. Can I do that in procedural php?
Thats a fair difference. I could give more than a few ways that you could hack up an equivalent, but I think thats a fair difference to site.
McGruff wrote:Objects give you all kinds of handles to pull on, parcels to pick up which just don't exist procedurally.
I think its more a matter of approach, but again, I think thats a fair difference. I'd say that classes are designed in a way that lends themselves to testing, but that you could duplicate most of it for procedural code.
The difference there is in importance and ease. The OOP world has a much better toolkit for testing, while procedural, you are essentially rolling your own (at least to my knowledge).
McGruff wrote:TDD - using tests as a design tool - is a really nice way to work; testing is about much more than just quality control.
I think thats the perfect statement, because it describes tests correctly: with a subjective preference ("nice"), it makes clear that some people won't prefer it.
McGruff wrote:This is a very common attitude you come across in newcomers to testing. Why do all that extra work? You'd really have to experience it to find out and I wish I could persuade you to stop bickering and give it a go. That's really all I'm trying to achieve here: help people to learn, as others have helped me.
I'm not a newcomer. I'm not inexperienced, and you continue to make assumptions about posters simply based on your own background. Its neither accurate nor fair.
Thats why lesson #1 in debate is to focus on the argument - the issue - and not the person.
McGruff wrote:Test-infected programmers don't really write code: they write tests and the code just emerges from the tests.. The reason for that, or rather one reason of many, is because it's easier to work this way. It saves time.
(I trimmed the comment a little, my apologies if I lost some context). The phrase "easier" is again a great choice: Its subjective, personal, and isn't absolute. However, following it with "it saves time" is a bit dishonest. For some it will save time. By example, it saves you substantial time. For someone that doesn't use tests regularly, it will considerably slow their development - you've mentioned the learning curve numerous times yourself. Thats not to say its a waste of time. Like you say in the end, its worth it in the long run.
My point was purely that there are situations where its not the ideal, and where it IS fair to say that it would be "less better", if you include development time as one of the criteria.
We're circling around the key issues, and its mostly due to delving into detail. The only question is "Is OOP always better than Procedural?".
We've discussed several situations where you've agreed that its not: From hello world, to shell scripts, from inexperienced testers who need to get up to speed with new methodologies, to projects that specifically define "better" to include development time.
Since you've agreed that there are *any* situations where OOP isn't better, we have to agree that OOP is NOT always better. I think everyone in the thread is in agreement that OOP is powerful, useful, and something to encourage. The difference from day one, that has always set MY hair on fire was your statements that implied that Procedural was inferior to OOP in every sense, or that people that prefered procedural were unwilling to learn.
Thats simply provably false.
OOP or procedural is absolutely a matter of preference. But going further, if you are a horrible programmer, NEITHER will solve that. Which puts more focus on the meta-issue: People should always look to improve themselves. That doesn't mean picking one and only one methodology! That means embracing the right tool for the job, and if you are more comfortable in Procedural, that may be the right tool until you get familiar with OOP.