| SitePoint Sponsor |
He may know what's going on NOW, just before handing the code to you, but if the code is bad, he will have problems if he's asked to modify or add new features to his junk later. And what if you'll need someone else to modify it? They will have serious problems to make sure the additions work well and nothing in the original gets broken.Originally Posted by Kiren
Yes, I completely understand thatI sometimes have the same problem with CSS designs :P
Well, Steve McConnell has done a great job of explaining it.
Last time I checked, I've been doing this for more than a few months.
Actually I didn't. Try reading that again in context. Someone asked, as an employer, how to sift wheat from chaff if you don't know anything about programming. Can you think of a better way to home in on the top tier of php developers?
This is all getting a bit personal. Not knowing about something and trying to learn about it is good. I'll try to help if I can. Not knowing about something and criticising those who do is bad, very bad. You'll end up merely starting a fight where instead there might have been a useful discussion from which you and others - including me - might have learned something.Too bad I don't have the time to get into some challenge, but I surely would like to see us both coding the same application in order to probe what you're saying
I don't think that's possible.
Look at their formal training ?
Or perhaps hire someone who you're sure knows his stuff, but who is too expensive/overqualified. But just hire him for a week, and use him as a consultant to assert the actual candidates.
I think that trying the program by yourself, pushing it to its ends, while pushing yourself to yours thinking of what happens and can happen, is sometimes the best way you can afford to know in a reasonably short time frame if a program is good or not.
Digging into the code, even if you are a trained developer, can tell you only if you have the time to do it with really the care and effort this always implies if you want to be effective. Plenty bugs that have annoyed developer teams and users for years have come from that: too fast and superficial inspecting of code (no matter with which tools, from visual fast reading, to automated test sets) - when it's not too fast tweaking of the code...
Paris, Mon 15 May 2006 16:39:45 +0200
My bad. I must admit I don't know exactly how long you're TDD infected, but for what I can remember it was not that long. Anyway, it really doesn't matter. I was trying to make a point. It wasn't never my intention to offend you.
As a matter of fact we are at work hiring PHP programmers at the time being and I'm given the task to screen them. I have seen quite a few, with good and less good PHP skills, and at the end, the ones that really got my interest have not been measured by their PHP knowledge, but by their analytic insight, their capabilities of writing well structured, well commented and clean code (whether it was Delphi, Python or Perl, it didn't really matter to me) and their overall attitude towards programming and developing. Those are the ones that have caught my attention, and those have been in fact the ones getting the chance.
The fact that I don't test by following TDD methods does not mean I don't know them. I read and investigate much more than you can probably imagine. It's just that I don't see the added value for me. Does that make me a worse programmer or developer? I surely do not think so and this is exactly what I meant to say. I may have not expressed myself that well, but trying to challenge you was not meant as a personal attack, just my way of saying I didn't agree with you.
There’s more than one way to skin a cat.
TDD is all well and good, but I've never seen it being practiced in an actual corporate environment. My overlords don't expect me to test my code. We have a team of QA people to do that. I am expected to churn out lots of code. Quality? Who needs it.
That said, I have experimented with TDD on personal projects, and can see how some might find it useful. Myself, I'll stick to more traditional methods of unit testing.
Back to the topic...
Part of the reason a lot of forums, phpbb specicially comes to mind, are a mess of a code is simply their evolution. The code base was created before there were strong OO capabilities in PHP, before there were thousands upon thousands of code quality advocates. In the short-term, more money is made by adding features...not by rewriting your existing (and functional) code base.
Another reason could be that most developers simply don't care. If you're careful, and you know what you're doing, and you don't care about future maintenance, what's wrong with globals? What's wrong with spaghetti code? What's wrong with procedural code?
The answer to all those is "nothing". Nothing is wrong with PHPBB provided you A) understand what's happening (I assume the developers do), B) don't care about ease of integration for outsiders (it should be obvious that this isn't a priority), and C) can ignore the pleading of morally superior coders.
I think you hit a sensitive spot. Php can be quite an "anarchic" environment. It's a good thing that you can jump in and turn out functional code easily. The bad side of that is that there are no clear standards, no path to follow for those who want to learn how to do a good job. Worse, if you try to promote things like OOP and testing, you often run into people who actively go on the attack despite having little or no experience of the subjects which they criticise. At that point my patience starts to wear thin. Not knowing something isn't a crime but not having a desire to learn is. I've had to deal with that more often than I would have preferred.
What I've never done is heard a serious critique of testing from someone who truly does understand what it's all about but nevertheless has chosen to reject it. I'd be interested to hear why you decided it's not for you.
I'd definitely agree with that. I'd have to. There's a Zend quick test (or whatever it's called) with a sample half-dozen questions from the Zend certificate exam. I failed. On the other hand I'd be comfortable giving a talk on test driven design - at least for an audience of beginners. If there's a technical detail I'm not sure about I'll write a unit test for it, and/or open up the manual.the ones that really got my interest have not been measured by their PHP knowledge, but by their analytic insight
Are JP Morgan in Glasgow corporate enough?
I'm writing a simple CMS at the moment. Currently I've got over a hundred test cases with around 2,500 individual assertions. The tests are run constantly while I'm working. It would be interesting to add a hack to SimpleTest to tally the total from the day I wrote the first line of code to the day it finally goes live. You'd be well into six figures. There's no way you can test with anything like that kind of rigour clicking around a website by hand. It's just not possible.My overlords don't expect me to test my code. We have a team of QA people to do that. I am expected to churn out lots of code. Quality? Who needs it.
And testing is about much, much more than merely testing...
Sure, but I've never seen it. I didn't claim it wasn't happening.
I agree with you, in theory. In practice however, there are ~200 people here whose sole job is to click through the website and find mistakes. It's not my job. My boss doesn't want me writing tests, my boss would be angry if I were writing tests.
The kind of testing you're talking about works wonderfully well in theory. In practice, however, it slows down the coding stage. Not the entire process, since it cuts down on the latter stages, but that's not what matters. Get it coded, get it out of our department, and let the maintenance programmers fix the bugs. That's our mantra.
Anyways, this isn't a thread to debate the merits of no-testing vs. unit-testing vs. test-driven-development. That gets discussed enough in other threads.
The thing about TDD is that it isn't just about testing, but its about design, and using tests to help you do so. Personally I prefer the Behaviour Driven Development way of looking things and Im maintaining a keen eye on the Ruby rSpec library - I look forward to moving from Test::Unit to rSpec.
Personally, I hate working without a good suite of unit tests now - I just don't have the confidence to refactor and be sure I'm not breaking anything without them, and I find that TDD leads me towards better, simpler designs.
That sounds like a terrible place to work. I don't know how you put up with it and I have to wonder about the quality of code churned out at your workplace! I dread to think. Its completely backwards and counter-productive - all you do is increase the time it takes to get feedback and improve code. With unit tests I can write a test, refactor and rerun the tests. The feedback loop is tiny so writing tests does not, in fact, slow development time in the slightest. Developing test first leads to me to a better solution quicker and enables me to catch and fix bugs quicker.The kind of testing you're talking about works wonderfully well in theory. In practice, however, it slows down the coding stage. Not the entire process, since it cuts down on the latter stages, but that's not what matters. Get it coded, get it out of our department, and let the maintenance programmers fix the bugs. That's our mantra.
> the ones that really got my interest have not been measured by their PHP knowledge, but by their
> analytic insight,
I would even venture as far as to say that if I was in your situation, and that someone proved to have a half decent ability at solving problems at the more complex level, and have no TDD experience, I'd be more interested in that individual.
Simple because given enough tutition, anyone can learn TDD, but that isn't the case with everyone in that there are those that have no ability at breaking a problem down and solving it, and in such a manner that the solution is environmentally safe in regards to the existing code base.
Really, this is the sort of stuff that determines if you are a developer or not in my eyes. Sorry for going off topic
Actually, that's the most important point about unit testing in general and test driven development in particular.
The term "testing" is actually a misnomer, as TDD is actually guiding the development.
Until venturing on this forum I'd never heard the term TDD, anyone got a few good links for me to read, specifically with examples.
Edit, scratch the above, I'm reading through lastcrafts site.
Would you like to try a quick TDD session using SimpleTest here on the forum?
Yes I would, I understand the principle but it's always nice to how how it should be done.
http://rspec.rubyforge.org/ is the website for the Ruby rSpec library which is a Behaviour Driven Development framework - similar in many ways to Test Driven Development but semantically different (but its an important semantic difference). Which ever semantics you choose, they both have a similar aim and I think the tutorials on the rSpec site are well written - you don't need to understand Ruby to follow them either as its more about the theory than the code (although the rSpec syntax is great and you should find it easy to understand anyway!).
Dave Astels' (author of Test Driven Development: A Practical Guide) original article on BDD can be found here.
Are there any plans to port rSpec to PHP?
OK
Not yet - Dave Astels is working on sSpec for Smalltalk but I'm not sure if the DSL-like syntax of rSpec (and probably sSpec) would port over to PHP that well. Perhaps it would be worth looking at jBehave for Java as inspiration instead (I'm not that familiar with it but I'm pretty sure its a similar principle) - it would likely port to PHP in a more natural way.
Heh, please do!OK
I'm just starting out with TDD, and to be honest, it's trickier than I thought at first. Any decent topic written in plain to read English would be a boon for sure
I'm trying to find the place where they actually give the variable a value.
You see, firstly, you look at index.php, then you find out the startup file is global.php, however, global.php includes init.php, which in turn uses functions from functions.php, then includes session.php which calls a function that find the userinfo from cookies.
Right now I have a DB error coming from somewhere (a cronjob), but I can't even find where in the system it is executing this query.
Perhaps docblocks could be used. PHP5's reflection api has a convenient ->getDocComment() method. Something like :
PHP Code:/** @context Stuff */
class TestOfStuff extends UnitTestCase
{
/** @should do foo when qux */
function test_foo_when_qux() {
}
}
Mmm...its not very DRY though is it? Seems a bit pointless.
Plus, you wouldn't be able to do stuff like:
PHP Code:(2 + 2).should.be 4
Posting Permissions
Bookmarks