Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Can I Make Testing Software More Stimulating?

Soulskill posted more than 4 years ago | from the flamethrowers-spice-up-any-chore dept.

Software 396

An anonymous reader writes "I like writing software. In fact, I revel in it. However, one thing has always kept me back from being able to write the best software I possibly can: testing. I consider testing to be the absolute bane of my existence. It is so boring and un-stimulating that I usually skip it entirely, pass the testing off to someone else, or even worse, if I absolutely have to test, I do a very poor job at it. I know I'm not that lazy, as I can spend hours on end writing software, but there's something about testing that makes my mind constantly want to wander off and think about something else. Does anyone have any tips on how I can make non-automated testing a little bit more stimulating so I can at least begin to form a habit of doing so?"

cancel ×

396 comments

Sorry! There are no comments related to the filter you selected.

sharks with lasers (5, Funny)

master_kaos (1027308) | more than 4 years ago | (#33270904)

just imagine if you don't test giant sharks with lasers will attack you.. with that stimulate you enough?

One word (1, Insightful)

Anonymous Coward | more than 4 years ago | (#33271112)

tele-dildonics hooked to the exception mechanism.

Re:sharks with lasers (4, Interesting)

arthur.gunn (1687888) | more than 4 years ago | (#33271208)

Or another way to make it more fun - Godlike!

http://github.com/gunn/godlike [github.com]

Plays a sound when you acheive 100% test passing rate. The default sound is the Unreal Tournament voice: GODLIKE, but you have as other sound options: headshot, killingspree, perfect, supreme_victory, ultrakill, flag_capture, and frag.

Re:sharks with lasers (0)

Anonymous Coward | more than 4 years ago | (#33271458)

Like the others have said, let thy paths of execution drive a game engine. Let thy flows of execution guide the automatic construction of a game filled with the puzzles of selection leveraging the cyclomatic complexities of thy code. Let thy assertions be the triggers for monsters. Blessed be the leaf nodes of the tree of life in the game.

This way, the chore of testing can become as fun as playing a FPS.

Too close to the subject... (5, Insightful)

bgibby9 (614547) | more than 4 years ago | (#33270906)

Personally I feel that the dev should never do the testing of their own code as they are too close to the subject to test every angle.

Sorry this doesn't answer you question :P

Re:Too close to the subject... (5, Informative)

SpinyNorman (33776) | more than 4 years ago | (#33271044)

The developer should unit test, and the test group should system test. The two are complementary.

The test group will hopefully test the software in ways you never thought it would be used, but you'll hopefully have tested every code path and end case that only you are aware of from having written it.

Of course the developer can system test do, or at least contribute test cases.

Re:Too close to the subject... (5, Interesting)

Z34107 (925136) | more than 4 years ago | (#33271220)

That's similar to what my workplace does. You're not really expected to test your own code - it's assumed that if you're handing it to a QAer that all the use cases you could think of are working. Instead, you get at least one round of "programmer QA" where another developer on your team examines your code for correctness and efficiency before handing it off to QA proper.

The QA folks do mostly UI and workflow testing; they're fairly technical, but they're not coders. If they manage to break anything, you get your code back to fix and the process starts from step one.

That seems to work pretty well - you're not testing your own code, but trying to break your coworker's code before QA gets a chance to.

But, how to make testing your own code interesting? I'm not sure about that - there's not much you can do to make unit tests interesting. But people finding your UI baffling suggests a lack of design. Have you ever done a mock-up and demoed it to end-user victims? They make us at least find other developers before we start throwing around hWnds.

You could try silly tricks to make it interesting (0)

Anonymous Coward | more than 4 years ago | (#33271444)

Or just pop some Ritalin.

Re:Too close to the subject... (4, Informative)

FooAtWFU (699187) | more than 4 years ago | (#33271488)

It's hard to effectively test after you've written code, because it is really boring. So I like the "test driven development" approach. You write the test first (or shortly after some very skeletal code) and when it passes, you know that you're done. (Well, or that you need to write more tests.) The time spent writing tests doubles as time to review and internalize the requirements of the task ahead of you. Benefits of the approach include extensive unit test coverage (which provides cover for you when you're refactoring) and uncovering (or sometimes even anticipating) boatloads of small bugs, long before they even hit QA.

the developer should participate in system testing (2, Informative)

ciaran_o_riordan (662132) | more than 4 years ago | (#33271530)

> The developer should unit test, and the test group should system test.

In my experience, the developer should participate in system testing too.

System testers have to know what the corner cases are. They can't guess them all (unless they're more skilled at each unit than the unit's developer is, in which case what's this product genius doing in the system test group!). Brute force takes too long for most systems, and even brute force requires knowledge of what variables to change and what ranges to span for each variable.

I used to program embedded systems for oil pipeline tools. (Not a sector with a glowing reputation for reliability right now, but bear with me.) The system testers had decades experience in pigging, hydraulics, tool operation, an ISO certification, but they weren't programmers. The whole team participated in system testing (or a member of each unit group did), so that we'd collectively know all the combinations worth testing.

(As for answering the question of the story, I think the asker really should have given a hint as to what sort of software it is.)

Re:Too close to the subject... (2, Insightful)

bgibby9 (614547) | more than 4 years ago | (#33271584)

I think my point is that, devs that do unit testing are contributing to the testing overall which is sweet, but come on, who ever makes unit tests that are 'decent' enough to ensure that the testing is done correctly?

IMHO testing should be done by people who CARE about testing. Devs who do shitty unit testing contribute to the facade that the testing is done and working properly but in reality a shitty unit test could mask other problems.

At that point you're creating more problems than you are solving!

Re:Too close to the subject... (1, Insightful)

Anonymous Coward | more than 4 years ago | (#33271608)

I think many of the (as usual, interesting and informative) replies are skipping over some essential questions. For whom are you writing software? A capitalist company with deep pockets? A non-profit with shallow? A small scale project (meaning, possibly you're the only author/developer) with a limited audience? I'm a so-called computer scientist researcher at a national laboratory. Testing is really important, but it's one of the last things I do. For me, the "test driven development" scenario doesn't work. Why? Because most of the code I write is just playing around with algorithms and ideas, figuring out what works and what doesn't. Example: someone asks me to code up something in OpenMP to do XYZ efficiently, on a platform with 256G memory. My first effort *should* work, but it keeps blowing out memory. So I code versions 2, 3, 4, and 5. In the meantime the requirements have changed, because the person I'm working for is also a scientist, and she's learned something new, and would like slightly different capabilities. I finally get something that appears to work, and then I wrote a few system-level test. My point (see first paragraph and ignore others) is that you haven't given us nearly enough background to coherently answer your question.

Re:Too close to the subject... (4, Insightful)

Chuck_McDevitt (665265) | more than 4 years ago | (#33271050)

The developer should never be the ONLY one testing the code. But the developer should absolutely test the code before turning it over to QA. You should be convinced your code works before giving it to someone else to test.

Re:Too close to the subject... (4, Insightful)

NorbrookC (674063) | more than 4 years ago | (#33271060)

When I wrote code, I knew how the program was supposed to work. I made the user interfaces "obvious" - to me. So my "testing" was along the lines of "does this compile properly," and "does it output what I expected it to?" The rude awakening came when I handed off the "finished" product to someone else. All sorts of errors I hadn't thought about handling happened, people were confused by the user interface, and more than one "oops" cropped up. While the "boring" testing you're doing on your code may catch the obvious things, it's always better to have someone else test it.

Re:Too close to the subject... (1, Interesting)

Anonymous Coward | more than 4 years ago | (#33271380)

Over time you learn to find joy in figuring out all the ways your app can go wrong and develop software that can deal with the real world. You sound a bit like a music student who doesn't like practicing their scales. Mastery takes time, like music. You can riff a bit, good for you, but you aren't developing software just for yourself (well, maybe you are). You are writing software for others to enjoy.

Re:Too close to the subject... (1)

BunnyClaws (753889) | more than 4 years ago | (#33271088)

Very true, but that would mean the company would have to employ a separate QA team. It seems many companies are too cheap for that.

Re:Too close to the subject... (1)

pspahn (1175617) | more than 4 years ago | (#33271508)

While working at EA right after high school as a phone jockey, we were occasionally asked to work an hour or two extra to help test upcoming games.

I was not typically interested, until they wanted testers for the new version of Madden (a favorite of mine at the time). So I went. I found bugs. I documented them thoroughly.

Part of the deal was that we got a free copy of the game upon release. I took it home, fired it up, and the first thing I did was check for the bugs I found. Every single one of them were still present.

So, is it a case of companies being too cheap? Or is it a case of companies being too wasteful?

Re:Too close to the subject... (1)

Sigma 7 (266129) | more than 4 years ago | (#33271628)

In this case, testing for bugs is meant to get a list of bugs before the game gets on shelves. That way, the developers have a bit extra time to figure out the problems, and release a "timely" patch for the players.

I heard that AvP2 had a patch before the game was released. They must have been following this concept, but mis-timed the patch release.

Re:Too close to the subject... (1)

Zero__Kelvin (151819) | more than 4 years ago | (#33271226)

"Personally I feel that the dev should never do the testing of their own code ..."

Congratulations, you get the prize for offering pretty much the worst advice ever in an ask slashdot article.

It may not be more stimulating (3, Informative)

NEDHead (1651195) | more than 4 years ago | (#33270910)

But you should be writing the test as you write the code

Re:It may not be more stimulating (1)

Joce640k (829181) | more than 4 years ago | (#33270976)

For coded tests (unit testing), sure.

Sitting and using the program? Not so clear-cut. The programmer usually never does weird stuff or tries to load massive files like the users do.

Re:It may not be more stimulating (2, Interesting)

Anonymous Coward | more than 4 years ago | (#33271242)

That's exactly whats wrong with programmers these days. They never try large inputs. Like say, more than 1024 characters for their 1024 character, null terminated string. They never try weird input, such as input containing single quotes. Not so clear cut? I say, very clear cut! Programmers, that can't think of weird or bad stuff to give their program to swallow should not be programmers at all. They don't deserve it. How can they write good and secure code, if they can only ever think of the most straightforward way of using their program.

That said, it is different from the repetitive and boring clicking through your application from a users point of view. But in that case, do automated user tests (where possible). Where not, get a grip. Force yourself to do boring stuff. Its a skill you need in life anyway. Trying to make things interesting only ends in creating over-engineered solutions.

I don't say the story submitter is such a person, but a lot of people write "interesting" software, rather than the software that is needed. You can make programming interesting and have fun all day long and in the end, the customer still doesn't have his application running, which should have taken a month to implement. Instead he gets a framework for a framework for a framework to create the application that he really wanted after 12 months.

Re:It may not be more stimulating (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#33271132)

Ug, another one of these myopic buzzword mantra.

In these days of framework overload, we are often dealing with parts of framework we are not familiar with. Try writing tests that's worth anything while you're figuring out how that part of framework hoopla works.

And yes, you are a stupid stupid person.

Re:It may not be more stimulating (1)

rxan (1424721) | more than 4 years ago | (#33271516)

I would say no under certain circumstances. When developing you often don't know how a function will work until it's "completed". I'll often write a whole class and only write the tests and documentation once I feel it's completed. When I write both tests and docs while developing I find that I end up rewriting the tests and docs. The functionality has changed from what I first imagined. Of course this wouldn't be too much of a problem with good design.

You can't? (0)

Anonymous Coward | more than 4 years ago | (#33270916)

How can I make assembly line work more interesting?

Re:You can't? (5, Funny)

Anonymous Coward | more than 4 years ago | (#33270942)

Wear a different hat each day.

Re:You can't? (4, Funny)

sohp (22984) | more than 4 years ago | (#33271342)

Wear a different hat each day.

I put on my robe and wizard hat.

Test Porn Software (1, Insightful)

Anonymous Coward | more than 4 years ago | (#33270920)

eom

Simple (5, Insightful)

Anonymous Coward | more than 4 years ago | (#33270930)

Add porn

How? (0)

martin-boundary (547041) | more than 4 years ago | (#33270940)

That's easy! Just use a Monte Carlo Method [wikipedia.org] .

Oh, wait, you meant stimulating? Nevermind...

Write more software (1)

croftj (2359) | more than 4 years ago | (#33270946)

I found that some of my best fun is to write software to test my software. Fortunately, I have written server code for a long time so I either get to write clients to exercise it or hardware device simulators to emulate devices the server talks to.

Loads of fun! Quite often, more fun than the SW I'm supposed to be writing.

logarithms (0)

Anonymous Coward | more than 4 years ago | (#33270954)

logarithms.

Start at a penny, and have the payout increase logarithmically for every bug found. Either you will end up with badass software, or you will end up bankrupt. Either way, it will be a fun ride.

Re:logarithms (1)

martin-boundary (547041) | more than 4 years ago | (#33271148)

You've got it upside down, AC (you from OZ or what?). Logarithms increase very *slowly*, log(1000) = 6.9

It's the exponential that increases fast, exp(10) = 22026.4

Focus your attention elsewhere (5, Insightful)

afaik_ianal (918433) | more than 4 years ago | (#33270970)

Does anyone have any tips on how I can make non-automated testing a little bit more stimulating so I can at least begin to form a habit of doing so?

No, I don't. I strongly think you're directing your effort the wrong way, and duplicating work if you're spending too much time on non-automated testing.

Software Engineers are not good at poking holes in their own work, so you should have someone else doing the bulk of that kind of testing anyway. You obviously need to do some cursory testing to avoid wasting someone else's time, but there are much better ways of directing your testing effort.

Focus on developing unit tests both before and during the development effort. Avoid developing your unit tests after writing the code though - your mind will be tainted with your approach, and you'll miss the obvious stuff. Not only do unit tests reveal bugs, the act of writing them will also help you get interfaces right, and help ensure a better overall design for your code.

Re:Focus your attention elsewhere (1)

Binder (2829) | more than 4 years ago | (#33271550)

This... definitely this. You generally cannot test your own work. You have too many assumption about how it works.

What developers SHOULD do is unit testing. One way to make this more bearable is to "code to the test". First create the unit tests which will prove your code does what it is supposed to.. then code until the tests pass. It's more like a game this way.

Re:Focus your attention elsewhere (0)

Anonymous Coward | more than 4 years ago | (#33271646)

I hear this claim that "Software Engineers are not good at [testing] [desk checking] their own code" and I just don't buy it. Put the word "lazy or egotistical" at the start of the sentence, and I'll agree with it.

Once I was managing a project where until you had learned how to do a lot of stuff to get your software onto the target machine, you couldn't test it even though you could easily compile it.

I gave a short term, highly paid, experienced contractor from a boutique job shop we had had success with previously a rather mundane programming task. The API was very well defined and I gave him a lot of ongoing guidance on things like priorities (space vs. time etc) as well as some suggestions on some implementation approaches. As I recall, the finished code was about 1000 lines.

When the contractor came to me and said "Okay, how do I test this", I looked at him and asked "Did you desk check it as I requested?" to which he replied "Oh yes". So since it was the end of the day anyway, I just took his listing (this was a few years ago!) and reviewed it at home while eating dinner or something. I found six very clear bugs that could be hit in normal use with proper and expected inputs.

The next day he came into my office and asked "So, did you find any bugs?" to which I replied "Yes, six". He then inquired "What were they?" at which time I just looked at him, shook my head slowly, and said politely "You find them". Note that I probably would not have done it quite this way with a regular employee but I had already decided that I wasn't to going to renew his contract so I was willing to use him as a guinea pig.

He went away for most of the day and came back at the end of the day and declared brightly "Okay, I found all six of them" (I esp. noticed his use of the word "them" -- I never claimed there were only six bugs, just that I had found six -- I never even told him that if I had read past the first 200 lines). We went through the bugs he found and he had found six okay -- however only five of them were ones I had found, he had missed one I found and I had missed one he found.

If I ever had this to do over, I would tell him there were eight bugs (even though I had only found six) -- I'll bet there's still a bug lurking in that code that he would have found if I had done so.

Anyway, the moral of the story is, testing or reviewing your own code is hard, but unless you're so egotistical to think you don't write code with bugs or so lazy as to not be bothered, it can be done IFF management gives developers time to do so.

I've always been pretty good at reviewing (for bugs, not style) and testing my own code -- but that's because I know I make mistakes and I don't find some bugs I just assume I missed them and need to look harder! And, yes, it is boring!

Stimulating? (1)

david@ecsd.com (45841) | more than 4 years ago | (#33270984)

Bring some porn to work and masturbate.

Duh.

More bugs (3, Funny)

MichaelSmith (789609) | more than 4 years ago | (#33270992)

Clearly there aren't enough bugs in the software you are testing. As an experienced C programmer I can help fix this problem...

Re:More bugs (4, Funny)

croftj (2359) | more than 4 years ago | (#33271134)

Let me guess, you can do that by writing your code in java or C#

Re:More bugs (1)

oldhack (1037484) | more than 4 years ago | (#33271316)

I can vouch for C programmers. They are experts - you can't beat them.

BDD (3, Informative)

Dishwasha (125561) | more than 4 years ago | (#33271012)

First off, don't do non-automated testing. It's unnecessary. Do Behavior Driven Development with Cucumber http://cukes.info./ [cukes.info.] It's massively more fun than unit testing.

Re:BDD (0)

Anonymous Coward | more than 4 years ago | (#33271104)

I was actually going to reply with this exact comment.. so I'll just second it.

I've been notoriously bad at testing in the past, and cucumber really hit a specific spot for me. All those times when I'd work on something and then double check that it still works is basically wrapped up in BDD. It's also pretty helpful to consider how I want to implement the feature by writing it out first. I sometimes deviate from that as I'm actually doing it, but it's been the thing I've put testing in a different light for me. It's not all perfect, but it's pretty great. I guess I also like that it documents things pretty clearly too.

write tests as you code (1)

largesnike (762544) | more than 4 years ago | (#33271018)

I know, I know, TDD is talked about ad nauseum, but I often find that when I've just written some logic, and I'm writing some tests for it, that I pick up quite a few bugs, and actually learn more about what I'm really writing.

Even so, some parts can still be boring, but at least, if you break it up and do it test-driven then you're not faced with writing 47-odd tests in one big lump, after you've written heaps of logic.

attention (1)

zeroRenegade (1475839) | more than 4 years ago | (#33271022)

people in the front rows may be exposed to some splash effects. some viewer experiences involve heart attacks, and conjunctivitis. (http://en.wikipedia.org/wiki/Conjunctivitis)

go functional (0)

Anonymous Coward | more than 4 years ago | (#33271030)

learn functional programming - scala or even haskell - kill unwanted side effects before they happen

Self questioning (1)

d3jake (1335521) | more than 4 years ago | (#33271032)

I've only done hobby programming for a couple of years, but if you find that testing isn't exactly your cup of dried leaves steeped in hot water, I would suggest viewing it as a challenge: If you love writing code, then it should follow that you like writing good code. The only way you can determine that is by trying to break said code. Sadly I don't usually need any additional helping breaking my code, as it often breaks itself, but by shirting it into a challenge against yourself, your code and motivation will benefit.

SMOKE WEED EVERY DAY (-1, Troll)

Anonymous Coward | more than 4 years ago | (#33271038)

This message brought to you by Carl Sagan.

coding = testing (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#33271048)

So it sounds like you have no fucking clue how to write unit tests. If you don't write those then your software is guaranteed balls.

Go work for a porn website (0, Offtopic)

PFactor (135319) | more than 4 years ago | (#33271052)

You'll get all the stimulation you want from your "testing".

Automate your tests (1)

masouds (451077) | more than 4 years ago | (#33271064)

You need to write tests for your code so that testing can be fully automated, with the issuing of one command. If there are no ways to automate your testing, you need to write software that allows you to do that, and then use it. If it is useful enough, you can even sell that.

QA sucks. (1)

Godskitchen (1017786) | more than 4 years ago | (#33271066)

Get used to it, comrade.

Re:QA sucks. (1)

AnonymousClown (1788472) | more than 4 years ago | (#33271202)

Oh, I wish they did! There were some hotties there!

Oh, that's not what you meant. Never mind.

Re:QA sucks. (1)

NegativeK (547688) | more than 4 years ago | (#33271214)

That's why we're paid. QAs: Doing the suck for you.

It's just who you are. (1)

ddt (14627) | more than 4 years ago | (#33271072)

I think it's just who you are, and you're probably wise to partner with others.

I'm quite the opposite. I like nothing better than to write a great benchmark, because I'm an optimization fiend. Also love to write a correctness testing benchmark, because it lets me check my optimizations for accuracy. However, I can't stand most high-level coding work, because I get horribly distracted. My brain gets distracted by what's happening on the metal when it doesn't matter at all, and then I get really bent out of shape about the aesthetics of the code, which for most jobs where you need to get things done doesn't matter much until you have something working, but for whatever reason, it's just hard for me to enjoy it.

A few challenges (1)

spaceman375 (780812) | more than 4 years ago | (#33271080)

First of all, try to break what you just wrote. Not hack it; just break it. Lean on the control key while typing input, feed it binary files for text & data. Run it in a VM on the slowest hardware you have. Make a game of trying to break your own code.

Then go back and do it again, but this time play black-hat hacker. Get creative rather than methodical. Try sql statements everywhere that might touch a database. Hammer every communication method it uses with denial of service abuse and then crafty mis-information that only you know enough to design.

The point is, make a game of it and you'll enjoy it. You could always trade code with a co-worker and keep score of how many bugs you each find in eachother's code.

good question (1)

darjen (879890) | more than 4 years ago | (#33271090)

I have the same problem. If you figure it out please let me know.

You need to get into Test Driven Development (4, Informative)

CodeBuster (516420) | more than 4 years ago | (#33271092)

Have you given Test Driven Development [wikipedia.org] and NUnit [wikipedia.org] a try? If you haven't heard of these things or taken one of the TDD frameworks out for a test drive then you owe it to yourself to invest some time. The software industry in general and the .NET community in particular is moving towards automated unit testing and Continuous Integration [wikipedia.org] . You should get on this train too.

Re:You need to get into Test Driven Development (1)

carlzum (832868) | more than 4 years ago | (#33271334)

I agree, developing tests after the fact is boring and forces you to remember what you did. When you create unit tests during the creative, problem solving phase it's much less of a chore. The end result is much easier to maintain too.

Reward yourself! (2, Funny)

LividBovine (1880104) | more than 4 years ago | (#33271100)

Allow yourself one porn^H^H^H^H^H download per bug found. Not only will this stimulate you, but you will be able to test with one hand.^H tied behind your back.

Change hat to a darker color. (5, Interesting)

Short Circuit (52384) | more than 4 years ago | (#33271114)

Imagine that the guy who wrote the code is the royal, snobbish jerk who always thinks his code is better than anything else. Realize that, at some point, he's going to make a change that will change the way the component behaves, and will yet again break your code that uses that component. Don't let him get away with it. Let your fingers pound as you write code to check for the smallest fault. Let your lips curl in a snarl as you feed it poisoned data. Relish in the thought that you can catch him in every slightest mistake. Think of all those things that might not think to catch in the future. Not just the important stuff that defines the role of the component, but those little things that some people might call "implementation details".

Also remember that he's the same jerk who wrote those unit tests that screwed you over all those times. Don't just pay it back; pay it forward.

Re:Change hat to a darker color. (1)

nacturation (646836) | more than 4 years ago | (#33271674)

Imagine that the guy who wrote the code is the royal, snobbish jerk who always thinks his code is better than anything else. Don't let him get away with it. Also remember that he's the same jerk who wrote those unit tests that screwed you over all those times. Don't just pay it back; pay it forward.

And when you finally catch up with this righteous bastard who wrote such lousy code, be sure to pound his goddamn skull in with a tire iron.

Do it the Microsoft way. (1)

amanicdroid (1822516) | more than 4 years ago | (#33271124)

Do it like the pros: release the software and issue patches.
The bug reports will be great fun.

I hit the save button and the program crashed. Thanks a lot asslick."

Don't test manually (2, Informative)

Scareduck (177470) | more than 4 years ago | (#33271140)

If you're not testing your code, you're not doing your job. Find ways to automate your tests.

Only write software you use yourself each day. (0)

Anonymous Coward | more than 4 years ago | (#33271152)

I've been doing this for the past thirty years, but I admit the previous ten years was hell.

Test Driven Development (1)

Giant Electronic Bra (1229876) | more than 4 years ago | (#33271154)

TDD is the best approach. Write unit tests BEFORE you write the code. First of all you'll be motivated to get it done. Second of all you'll write MUCH more testable code and thus spend a lot less time on testing. In the long run you will actually get to write more fun stuff than if you didn't do it this way.

Honestly, not all testing will ever be fun, but there's really no point to writing bad broken software and untested software is invariably bad software. Honestly though whatever organization you're working in should be insisting on this kind of process anyway. First thing I do when I set up a team is get the unit testing process up and running.

Your asking the impossible (1)

Kitkoan (1719118) | more than 4 years ago | (#33271168)

Its like asking "How is the most stimulating way to self file my taxes?" The answer is most likely there isn't unless you're of the rare few that do enjoy doing just that. Easiest way is to just hand it to someone else and get creative in forms of payment, maybe booze or some movie/music/game they want for doing it (everyone is different).

Unit testing achievements (5, Funny)

hansamurai (907719) | more than 4 years ago | (#33271174)

http://exogen.github.com/nose-achievements/ [github.com]

        *
            Instant Feedback
            A suite of at least 50 tests takes less than a second to run.
        *
            Coffee Break
            The suite takes between 5 and 15 minutes to run.
        *
            Take a Walk
            The suite takes between 15 and 60 minutes to run.
        *
            Take a Nap
            The suite takes between 1 and 5 hours to run.
        *
            Take a Vacation
            The suite takes at least 3 days to run.
        *

            Coming soon!
            Anticipation
            One test in a suite of at least 10 is slow, and all the rest pass.

Time

        *
            Night Shift
            Make a failing suite pass between midnight and 5am.
        *
            Punctuality
            Make a failing suite pass at 9am (give or take a minute).

Failure

        *
            Complete Failure
            All tests in a suite of 50 to 999 fail.
        *
            Epic Fail
            All tests in a suite of at least 1,000 fail.
        *
            Minor Letdown
            All tests in a suite of 10 to 99 pass...except the last.
        *
            Major Letdown
            All tests in a suite of at least 100 pass...except the last.
        *
            Happy Ending
            All tests in a suite of at least 10 fail...except the last.
        *

            Coming soon!
            Heisenbug
            Make a passing suite fail without changing anything.

Errors

        *
            Sausage Fingers
            Cause at least 2 distinct syntax errors in a single run.
        *
            To Understand Recursion
            Exceed the maximum recursion depth.
        *

            Coming soon!
            To Err is Human
            Cause all tests in a suite of at least 50 to fail with a single error.

Size

        *
            My God, It’s Full of Dots
            The suite has at least 2,001 passing tests.

Frequency

        *

            Coming soon!
            OCD
            Run the suite at least 5 times in the span of a minute without changing anything.

Coverage

        *
            100% Code Coverage Level x
            Cover 100% of at least 2x+7 statements with passing tests.

Libraries

        *
            Are You Mocking Me?
            Import a mocking library with at least one passing test.
        *
            Great Expectations
            Import the Expecter Gadget library.

Refactoring

        *

            Coming soon!
            Successful Refactor Level x
            Change at least 2x+5 lines of code between two consecutive passing runs.

recreate the stanley milgram experiment (2, Funny)

circletimessquare (444983) | more than 4 years ago | (#33271186)

http://en.wikipedia.org/wiki/Milgram_experiment [wikipedia.org]

except for you, the shocks will be real, and you will be both tester and test subject

every time your code throws an exception, make it so you receive a small, incrementally growing shock

after about 10 or 20 bugs, and the growing voltage of the shocks, you should be breathing heavily and sweating and be focused like a laser on ensuring the integrity of your code

The bad parts of coding (1)

Kurofuneparry (1360993) | more than 4 years ago | (#33271222)

I hate going over old, poorly commented code.

I hate testing code and looking for problems.

I hate debugging inexplicable errors.

What to these all have in common? If you write good, smart code with the right tools you'll not have to do as much of them. Others here have mentioned automated testing and I think that's great. I am no big expert, but improving the way I write code and the tools I write it with reduces the onerous parts mentioned above. I don't do all my projects with automated testing (I probably should) but it helps when you have it.

So, as far as it works for me, I would look first at the way that you program (big bites vs tiny bites, languages, structure) before I would look at the way you test. Testing always sucks. Then again, I'm an idiot.....

Way to help the pain = Write a test harness! (0)

Anonymous Coward | more than 4 years ago | (#33271232)

If you write a test harness, you know that the code is testable.
Then you can write tests OR you can hand it off to someone else to write tests.
Either way, the pain factor goes down as the time to develop tests after the harness is developed goes way down = less pain.

I am a Test Professional of 11yr.

Read The Daily WTF (2, Insightful)

Red Storm (4772) | more than 4 years ago | (#33271236)

http://thedailywtf.com/Default.aspx [thedailywtf.com]

The threat that one day someone will post your code and or screen shots from your programs for everyone to ridicule should be motivation to either improve or write worse code.

Simple (1)

crf00 (1048098) | more than 4 years ago | (#33271250)

Create some bugs in the unit test and hunt them down!

That's why we have automated tests (1)

Jadeus (58441) | more than 4 years ago | (#33271256)

Before becoming test-driven I would manually test my stuff, using my judgement to determine the scope of what I'd test. When I became test-driven I saw how writing those tests was like writing the code on the other side of the coin. The design is so clear and beautiful when it's exercised in a suite of tests. I enjoy writing (unit/transactional) tests because it proves how awesome my code is, and is much better at keeping it that way than I am while I'm busy building something more interesting.

Make it Automated (1)

n2rjt (88804) | more than 4 years ago | (#33271262)

Write a test framework that lets you expand the scope of automated testing.

well it seems obvious... (1)

fade (4063) | more than 4 years ago | (#33271264)

Build better bugs, experience more fruitful testing.

Curse of the programmer (1)

FullBandwidth (1445095) | more than 4 years ago | (#33271272)

Ever hear the expression "I'd rather write programs that help me write programs, than write programs?" Maybe you can get some enjoyment out of writing the code that helps you test the code you're writing. Write a perl script to test your C code, etc.

Write a program... (0)

Anonymous Coward | more than 4 years ago | (#33271310)

Write some software to test it. Then another program that will test that, et cetera...

How about testing the test? (1)

Skapare (16644) | more than 4 years ago | (#33271332)

You've just written some cool new fangled program for something. Maybe it automates a process. Maybe it creates a new interface for something. Maybe it's the next app killer. And best of all, you wrote a test suite for it during the development.

But does the test suite itself work right? How do you know that your test suite tests correctly, and completely? Did you also write a test suite test, too?

Make it a game... (2, Interesting)

LynnwoodRooster (966895) | more than 4 years ago | (#33271348)

I hate testing too! So I devised a little game with a compatriot in code: we unit-test each other's code. Each class is unit tested by the other person, and whoever finds the most bugs wins. What do you win? Usually pizza and beer. Free lunch or dinner can be a strong motivational reason, plus the chance to brag about trouncing the other person. Makes you a MUCH better "defensive" coder, always thinking about how/which parameters to validate, return codes, etc.

Explosions! (1)

Kepesk (1093871) | more than 4 years ago | (#33271442)

An even better game... rig your machine up to an explosive device and program it so that if you get the same error message three times, BOOM!

That's exciting, right?

Blowjobs (0, Redundant)

antifoidulus (807088) | more than 4 years ago | (#33271356)

Pay a hooker to test you software and if it doesn't crash, and ONLY if it doesn't crash, have her give you a blowjob. Case closed.

How about "You're fired" (0)

Anonymous Coward | more than 4 years ago | (#33271370)

Seems to me if you don't want to test then you aren't interested in doing professional quality work. Pass it off on someone else and you're shirking responsibility. Do half-assed testing and your undiscovered bugs impact the client's productivity. No matter how you slice it, you're fired.

From a professional tester.. (0)

Anonymous Coward | more than 4 years ago | (#33271402)

Learn to write good unit tests and think of them as writing code. It will save you time and effort anytime you update the code and you won't have to labor through the boring manual stuff quite as much. If that doesn't work, find a new industry. Testers hate developers like you and you just waste the time of everyone downstream. As much as you hate testing your code, your testers probably hate it more because I am sure it rarely actually works right with anything other than the rosiest of scenarios.

Testing is a stimulating factor (1)

rxan (1424721) | more than 4 years ago | (#33271438)

I'm a test developer right now, so this may skew my opinion. When I develop any code, whether it's tests, frameworks, utilities, or actual development, I always consider testing of my own code a stimulating factor. Do you enjoy knowing that your code works as you intended? I do. In my opinion good design is reflected by good testing. If your tests are bad then you won't know if your design is good either. This includes performance testing.

Try this: do no testing at all for a month and see how annoyed you get by receiving a million defect reports.

Then you are lazy. (3, Insightful)

Alcoholist (160427) | more than 4 years ago | (#33271446)

"It is so boring and un-stimulating that I usually skip it entirely, pass the testing off to someone else, or even worse, if I absolutely have to test, I do a very poor job at it."

Which sums up why software is so shitty today. I seriously hope that you don't write software for the areospace industry because I don't feel like falling out of the sky because you were too bored to test your code.

Every job has its boring moments, testing your code is one of those things that programmers must do. Should do, it encourages discipline and discipline is what makes good code. You can automate the testing to some degree but at some point you've got to poke it and prod it yourself because computers are stupider than even we are. If you can't hack that, find a different line of work.

Simple: (1)

Tablizer (95088) | more than 4 years ago | (#33271462)

Outsource testing to India. That's their punishment for taking our programming jobs ;-P
   

Nope. (1)

fatbuttlarry (1347443) | more than 4 years ago | (#33271472)

No, there is no way to make testing interesting. I hate it too. Its a "necessary evil" like grooming a dog. The dog survives without it, but that tick infestation can really stress your life out with bugs coming from all directions and showing up in places you never could have imagined.

Think of it as breaking it (1)

Farlan (1145095) | more than 4 years ago | (#33271500)

As a software analyst and a QA engineer, if you think of the software you write as if it were someone else's (preferably someone you know is a poor coder), test the software with the objective of breaking it, and finding those loopholes which will allow you to use the software in ways it wasn't designed to be used. It makes a very monotonous task so much more enjoyable.

Testing more interesting (1)

gwgwgw (415150) | more than 4 years ago | (#33271514)

For me the interest is raised if I write a few high level tests BEFORE doing any coding. Then code.

I suspect the heightened interest is the pleasure of writing to a spec and meeting a goal.

So often (80% of the time?) I then early on save a good bit of rewriting.

You can't, so don't try (4, Insightful)

a9db0 (31053) | more than 4 years ago | (#33271544)

I do software QA for a living. And if you're not a tester, don't try to be. It's your job to write code that meets spec, runs clean, is efficient and effective. Write it well. Write it secure. Write it to handle errors from data, users, networks, etc. Double check that you validate input. Make sure it doesn't leak memory. Write good unit tests. Test it enough to make sure it works. Then give it to a tester.

Good software testers are a different breed. They are a sceptical, picky, pedantic, detail oriented bunch who take new code as a personal challenge to find the inevitable bugs. They will test your code a dozen different ways you would never think of. They will find bugs that could not possibly exist. They don't care that your shiney new whistle or bell will be the next big thing that will make you all rich. They care that it doesn't barf when you pass it a string with more than 256 characters. Including special characters. In German. Or Japanese. They care that when it's been running for 12 days straight with automated stuff beating on it that the memory usage hasn't ballooned. They care how it deals with data files 10 times larger than you say it should handle, or runs on a machine with half the ram it should have, or handles twice the workload it should - because somewhere out there is a user who will ask it to. They will chew it up, spit it out, and ask you to fix it. Then they will do it all again.

Testers are a strange bunch, and good ones are hard to find. Find some good ones and cultivate them. They are a lot cheaper than a ticked off client.

Face it... (0)

Anonymous Coward | more than 4 years ago | (#33271546)

you're just lazy.

Cultivate a bit of self discipline (2, Informative)

JuzzFunky (796384) | more than 4 years ago | (#33271548)

You don't need to make it more interesting, you need to make it part of your routine. It's like waking up at 6am to go for a run. The first few times you do it it'll be hard, but if you stick to it and do it every single day it will become just something you do. Start small - don't try to run a marathon in your first week, just don't make any excuses or invent reasons to skip it just this once. The fact that you care enough to ask slashdot suggests that it is important enough to you to make the effort. If you can make the change and stick to it you will probably find more fulfillment in your work.

It is part of your job (1)

luis_a_espinal (1810296) | more than 4 years ago | (#33271578)

I like writing software. In fact, I revel in it. However, one thing has always kept me back from being able to write the best software I possibly can: testing.

It is part of your job... testing that is. Just do it. Not every part of your job is supposed to be tantalizing or pleasant. If it were, it wouldn't be a job. It's just part of what a job is. And doing those things that are necessary (even if they suck) is part of being professional. Testing does suck balls sometimes, but hey, if something sucks, do it more until it stops sucking (either because you became proficient or numb.)

I consider testing to be the absolute bane of my existence.

Your outlook on things certainly won't help in making things better, will it?

It is so boring and un-stimulating that I usually skip it entirely, pass the testing off to someone else, or even worse, if I absolutely have to test, I do a very poor job at it.

In that case, please do the world a favor and stop writing code. People who do this kind of shit is the type of people who say "done" even though all they have done is to check if their code compile and works with the happy cases. People like that are the bane of proper software engineering. By not doing this crucial part of your job, you are being unprofessional and unethical, and you should return a fraction of every paycheck proportional to the time you should have invested in testing.

Before looking for making things interesting, you should try having some work ethics.

Thank you. (1)

pspahn (1175617) | more than 4 years ago | (#33271596)

This Ask Slashdot was very informative. I'm serious. I liked this one. It's a good question.

Soulskill +1 : Relevant ; +1 : Motivational

Answer: don't. (1)

Ralph Spoilsport (673134) | more than 4 years ago | (#33271624)

Do your unit testing, but otherwise: Hire a QA engineer. If you test your own stuff you won't see the mistakes.

Allocate time and budget (0)

Anonymous Coward | more than 4 years ago | (#33271630)

Don't know about you, but I find that the problem with system testing is that more often than not, the project is already overdue, overbudget, and you're completely over it. Plus, you've got ten other things waiting for you, so testing something that is already "done" is a huge pain.

I certainly know how it feels. On the other hand, I know that the times I add the testing to the initial estimate, that bit of the estimate doesn't get chucked out, and the estimate turns out to actually be accurate - there is nothing more absorbing than meticulously going through every bit of the program that you wrote and polishing till it shines. If you've got the time.

Sure about that? (1)

Kostya (1146) | more than 4 years ago | (#33271656)

"I know I'm not that lazy, as I can spend hours on end writing software, but there's something about testing that makes my mind constantly want to wander off and think about something else."

Well, actually, that is kind of lazy :-)

Seriously: you do the parts you enjoy and you skip the parts you don't. That, my friend, is lazy. Or at least undisciplined. And if you are getting paid to do it ... well, that's just unprofessional.

I'm not trying to be a jerk, it's just that I have been at this for 15 years, and I constantly run into people who don't bother to test. It pays off in the long run, it makes for better software, and it makes you a better developer ... you just have to have some professional pride and buckle down. I mean you know that you need to, you know it would make better software, and yet you can't seem to find the interest/sel-interest/professional pride/whatever to do it? Don't you see a problem there?

You're better off than the tester. (0)

Anonymous Coward | more than 4 years ago | (#33271664)

Just remember, we testers would also prefer to be coding. Testing other people's code sucks, especially when we're the first ones to try it. So keep yourself chipper by remembering that you were the one who was smart enough to pursue a career in programming so that you only have to test 5% of the time instead of 95% like us lowly testers whom you outrank. In case you're curious, QA guys get over the testing blues simply by worrying about other things, such as rent checks, a lack of respect, and job security.

how to make non-automated testing simulating? (3, Insightful)

BLAG-blast (302533) | more than 4 years ago | (#33271690)

Simple. Automate it!

I used to dislike testing until I learn how to implement code designed to be tested. Use a dependency injection frame work (that will keep you busy for a while) and write testable code. Writing elegant, readable code which scalable and testable is not an easy or boring task. If you can not automate the tests, you are probably do something wrong.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>