The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

When are people ready to learn to test?

I'm not only test-infected I try to be a test-infector. I see testing as an essential technique which is important to encourage. Normally I'll tell people to start learning about testing as soon as they start learning about OOP but I'm beginning to wonder if that's correct.

The thing is, it takes a while to learn to create good OOP code. You'd probably expect that someone would go through several stages where they tear up everything they've got and start again from scratch. Testing makes that much harder. All the parallel work invested in the tests also has to be torn up. You could say that they're gaining useful experience of writing tests even if they are ultimately going to be scrapped but the individual in question might be wondering if it's really worth the effort.

First attempts at OOP code won't be well-conceived. Responsibilities may not have been clearly identified. Classes will probably be trying to do too much. They might cut across application layers. All this makes them much harder to test compared to lean, tight classes which do just one thing: will this also taint their first experience of testing making it appear to be a much more awkward and difficult tool to use than it should be?

Although XP shuns big up front design, I suspect there is more looking ahead going on than is sometimes acknowledged. Maybe the difference is just that XP'ers aren't looking too far ahead. Whatever, experienced developers will instinctively tend to make good design choices and so they're less likely to get into a position where they have to tear up entire systems. If they do get things wrong, it's probably not so bad that it can't be refactored back on track rather than scrapped en masse. The classes which they write will be easier to test - they'll know how to deliberately write them that way, as far as possible. They don't suffer the same pain as a learner.

So what do you think? Is there some kind of minimum skill-level to be attained before testing really starts to click? At what point are newcomers to OOP ready to start learning to test?

They don't need to know what a class or object is, all they need to know is the syntax to write a test case. So i think it can be useful from the very beginning when they start to learn the syntax.

Yeah, before they get bored and tired. They are not going to understand why they are testing to such a degree, especially when they do their first Hello World program. I mean, in all honesty, when you first start learning programming you think you should also learn to do unit testing. I think, in the beggining, an upfront-design is good. Otherwise, they will never get off their feet. XP programmers usually are good programmers, with experience, who can already form good designs easily. They can already imagine the solution, even when complex. Someone new may not have as much foresight.

Although, OOD and TDD seem to go hand in hand very well, i don't think that the use of a testing framework is exclusively for OOP.

As an example: I remember when i started programming php is that i had a lot of calls to echo, to make sure variables had the values i expected. And every time i wanted to make changes, i uncommented them to test again, or i surfed to the page and clicked around to see if i didn't break anything. Once they get bored of this repetitive task, they'll be happy to discover a testing framework that allows them to do this for them..

I think there is a distinction between learning OO and writing production code. I think automated test tools are great whatever paradigm is being used (after all there are SQL units and even a Haskell unit). It's especially beneficial when working within a team. But that's the working environment.

I agree developers should be allowed to cut loose when learning. If testing is not the first habit then what is?

It seems that most developers do a few large package style objects and then jump straight into designing a big system. They get stuck, read up on design patterns and then get even more stuck. At this stage they have gone so far in the wrong direction that just sitting next to an experienced OO'er for ten minutes is a complete revelation.

The experienced developers start small. They use OO to avoid design, using it's small scale fluidity to play.

Part of this has got to be to do with preconceptions about OO - the hype. The "reuse" argument is totally outdated. The expectations are all wrong and the learner is doomed to repeat the mistakes an entire industry made twenty years ago. Big UML diagrams look impressive, but like the flowcharts from the dawn of time (1970 for programmers), they are usually created after the fact. It's all so misleading.

I haven't yet seen a codified method to teach OO. The industry needs one and the PHP community needs one in particular, because of the number of developers at that stage of development.

I have been thinking about these issues for some time. I am trying everything I can think of within my PHP|Arch column as that's it's main subject. I have also a qualified teacher. I have been coaching developers for some time. I don't have a clue.

Yes, it takes a while, but only if he first learns how to write procedural code.
There are many OOP advocates that recommend OOP as the first programming approach learned.

I disagree. Either way, it is is going to take a while to be good at designing. Much like even if you start writing procedua code, it is is going to take a while to be able to write code with a good design.

How many OOP advocates have studied new programmers starting with OOP and skipping procedual? Are they better for it? Most OOP advocates themselves started with procedual.

Almost everyone who says take testing and OOP in one go, didn't do that themselves. They wish they did, but in truth, I think, they forget the struggles of tackling OOP on it own, let alone learning other concepts at the same time.

How many OOP advocates have studied new programmers starting with OOP and skipping procedual? Are they better for it? Most OOP advocates themselves started with procedual.

Almost everyone who says take testing and OOP in one go, didn't do that themselves. They wish they did, but in truth, I think, they forget the struggles of tackling OOP on it own, let alone learning other concepts at the same time.

just sitting next to an experienced OO'er for ten minutes is a complete revelation.

Small steps, and constant feedback would make a huge difference. I'm assuming that people are often learning on their own in which case they'll be getting that from the forums - this one mainly. I don't know anywhere else really with the same level of knowledge. (Incidentally, I started a Unit Testing forum recently on devnetwork.net to try to generate more interest there). If you're lucky maybe there's a local XP group although chances are they'll be talking java.

Indeed, we did and I would think that in about 50% of people, any benifit is either here or there?

But in saying that, people (as humans) for the most part need to walk before they can run, so what I'm saying is that people will first learn procedural programming first, and then move to object oriented programming either as a learning skill (the enjoyment of it), or they need to move forward to make their lifes better and easier.

In that same respect, TDD is the same. People will use TDD for just that same reason. I use TDD but not all the time, so I still use print_r( ... ) on occasion? Does it mean as stated in an earlier post that I'm just not (yet) bored?

I think what McGruff is doing by promoting TDD is a good thing, even though at times, he comes across as being too pushy, there is no error for someone to learn TDD early on in their development.

I think what McGruff is doing by promoting TDD is a good thing, even though at times, he comes across as being too pushy, there is no error for someone to learn TDD early on in their development.

I had a long reply, but it was so coherent and random, I just deleted it. I just can't think at the moment, couldn't get a point accross, so I am going to keep this simple by answering McGruff closing questions. I would say, though, that I mostly agree with you. There is nothing wrong with tackling TDD early in their development. However, it should be because they see the benefits, because they want to, and because it makes sense too, for them.

Originally Posted by McGruff

So what do you think? Is there some kind of minimum skill-level to be attained before testing really starts to click? At what point are newcomers to OOP ready to start learning to test?

I agree with what you are saying. I think there is a minimum skill, and that is after learning OOP concepts in theory, exploring them at least a bit in practice and also have observed and studied good, solid code on how things should be done. They are ready to start learning to test when the benefits of testing sound attractive. When they have encourtered problems, which they realise now they could avoided by testing. In other words, they have a convincing reason to start testing.

Of course, like everything, it depends on the person at hand. In general, though, I feel this applies to most people.

I'm not saying that you shouldn't encourage people to learn about testing early on - that's really what my instinct would be. I just wondered if it's the right thing to do.

I've been involved in some discussions on another forum where someone has been experiencing some testing frustration. The person in question isn't a beginner and I think the design issues at the root of the problem will just click into place soon but it did give me pause for thought, wondering how a complete beginner would react to testing.

I'm tempted to start posting to the php manual expressing php native function behaviour in terms of tests. It would maybe encourage bad practices though. If you "test" php, the tests are following the code (the aim is just documentation) rather than the code following behind the tests.

I use Simple Test and find I have at least as much test code as source these days. I have done so by cobbling together examples gathered around the web to deal with whatever I was working on. I find the experience a positive one in that I see the benefits of tests on my code quality and stability. But I have to say I find the process inelegantly unsatisfying. Writing tests is tedious programming at best and test code must be maintained as well as source so my codebase has doubled. So I would hardly consider myself "test infected". And I think the source of my bland reaction to testing is that it is dull and there is a great lack of automation of the repetetive tedium.

I find one hurdle to doing test driven development is learing the testing tools for all types of tests. And I notice that there is no standard templates on which to base tests. I see test code posted that varies from author to author but does essentially the same thing. Maybe it already exists, but it would be helpful if there was a test generator for the basic templates for testing. Plus, here seems to be no guidelines or consistency for test method names, or how the reporting code is organized. I notice that even lastcraft's test code has changed over time.

The basic things you want to do are: create tests for a class, create a mock, create a web test, etc. And you may want to create a template to initialte TDD where you want to start with a basic tempate that is designed to grow. Or you might want to write tests for an existing class where you want the generator to ask (or find through reflection) the names of all the methods and create templates for each.

Perhaps there are some guidelines and templates and generators that create templates that use those guidelines, but I haven't found them.

In reading McGruffs comments I think there is a difference between getting to think in terms of tests and to think in terms of the application you are trying to build using tests. There are regular posts from those who claim to be "test infected" dismayed at those who are not, never seeming to consider that there may be a (large) group of programmers who will never be "test infected" but would still like to use unit testing and would benefit from it. I think if the "test infected" as like people who like to brew their own beer. They seem to love all the work, but I just want a pint.

Dull, tedious and unsatisfying? I find it a lot of fun compared to what I was doing before. For starters no more demoralising bugs where you haven't a clue what's going on and start to wonder why you ever wanted to get involved with programming. With tests, you feel like you're back in control and never more than a short step or two off course. There's more pride in the carefully-crafted code which results from the discipline of writing tests. This can throw up all kinds of issues you might not otherwise have realised. More thought - and work - goes into it but that's a good thing. It saves a lot of time in the long run. You could design and build a car quicker than a plane but you'll travel further and faster once you get airborne.

I'm not sure how much scope there is for generating tests. I do have some templates and a script which I use to create a bunch of files for a new class, test & runners but they don't contain anything more than some includes, a skeleton class with no methods, and a sekeleton test with just one failing method which opens in the browser. That helps a bit but the real work in writing the tests has to be done by hand I think. Sometimes, you find a group of classes which share some test methods. These could be put in a shared test case and then subclassed for any class-specific tests but that's rare.

There is a fair bit to learn and I suppose it's not easy to do that on your own. All the more reason for a bit of cheerleading (beerleading?).

I understand that you find it fun. And I think that unit testing software is written by people who find unit testing fun and satisfying. My theory was that because they cannot imagine that anyone might think differently, they cannot build tools useful to those who do.

I understand where Christopher is coming from. Sometimes I get the urge to just pound out some code, and I have to remind myself to slow down and write the tests. It does occasionally get to feel tedious at point.

The main benefit I see is the confidence though. Now I never write a chapter, article or presentation without unit testing everything, because I want to be absolutly sure I know the code is working in those areas.

At work, I simply set up the rule that we do not migrate code unless there are accompanying unit tests. No tests, no migration. This certainly does wonders for motivation

It is not always easy to do, but when you can express a bug report as a failing test case, you can increase your confidence that a) you solved the bug and b) you have no re-introduced the bug at a later date.

I definitely agree that learning to do OO well takes time, and becoming a good programmer also takes time. For a beginner take those two together, and not only will Testing mean a lot more work for them, it will also disillusion them and give them a false sense of security: Writing tests that can effectively be a safety net, takes practice too, and not only does it take practice, but I would even go so far as to say you have to have a medium level of experience in programming before you will be writing tests "that matter".

Yes, [to learn to create good OOP code] takes a while, but only if he first learns how to write procedural code.

I disagree with the statement the way you phrased it. Even for someone with no experience at all, it takes time and making mistakes until you learn to write _good_ OO code (even if some zealots [luckily not here] will claim that is is "natural", "intuitive" or "everything is an object in the real world, too").

However it is true, that some people generally prefer to stick to one thing once they learned it, but this is more of a problem of the mindset of a that person, rather than an observation on OO or procedural). The same people will also have troubles learning the relational model properly if they started out with OO first (and no, we probably don't want to get into that debate...).

OK, so McGruff likes running tests and arborint dislikes writing tests? At least there is no fundamental disagreement.

I like coding-by-writing-tests. There's a fundamental change in perspective: rather than setting out to write code, you write tests and the code emerges while you're testing. The constant, detailed feedback is great and I enjoy the way it encourages you to craft better code. Oddly enough, you're at the same time more focussed on details but less bogged down in the details. I'm not sure I can explain what I mean there but that's really what makes it more fun for me. I want to think about the big picture.

I didn't really mean to disagree - actually it's exactly this kind of feedback I was looking for.