views:

478

answers:

10

I want to write tests for my app, though each time I look at rspec.info, I really don't see a definite path to take towards "doing things right" and testing first. I watched the peepcode videos on rspec more than once, yet it doesn't take. I want to take more pride in my work, and I think that testing will help. How can I break through this mental block?

+4  A: 

I was hating it until I started creating a few testing macros. Like logging in or getting to the homepage. I found it fun to start poking at what my testing framework could really do. It also helped to have someone else get me started by writing a few. Right away I found obvious improvements which made me want to get in there and start improving things.

thrashr888
+1  A: 

You need to see the value that testing will bring in refactoring and extending your code. Once you have a set of tests that define the behavior of your classes, you can then feel free to start making changes to improve the code. Your tests will provide the confidence that what you're doing isn't breaking the system. When you go to add new functionality to your code, running your existing tests will give you confidence that the new code you've added doesn't break anything else.

The key is to take that long term view. Testing is an investment. It takes a little bit away from the code you could be writing but eventually it will start paying off with interest. The capital that you have stored up will make it much easier to move ahead more quickly when adding new features.

tvanfosson
+1  A: 

Assuming you already have a list of bugs to fix, I always like to go back through and where ever possible create an automated test that demonstrates the bug. Then fix the bug and watch the test pass. Since you have to test the bug anyway, and the bug should already give you enough information to recreate it, you can see an immediate return on your tests.

Eventually, you'll start to get a feel for putting the tests together and how to write them, and you won't need the "blueprint" of an existing bug.

Brian B.
+5  A: 

Find tools that will reward you for testing. For example, make it very easy to run all the tests and get a message like

73 tests passed.

Try random testing because you can test against a lot of values quickly and easily.

See if your language provides a test-coverage analysis tool that gives you percentage of statement coverage or percentage of block coverage. It is very rewarding to drive code coverage from 60% up to 90%---and if you are lucky, you will find bugs.

My key advice is to quantify your progress in testing so that you can see the numbers going up. That will make it a lot more motivating. (Gee, I wonder what other numbers that go up can be found on this site...)

Norman Ramsey
+2  A: 

Think of it like this: if you don't test, your code is broken.

Ryan Bigg
+2  A: 

"Test things you don't want to break."

It might be helpful to prioritise at first. I know that typing out the full three layers of model, view, and controller specs on top of the cucumber acceptance tests can be a chore. So one idea is to just test the most critical things in your app, and add tests as you run into bugs you don't want to see again.

"Always start with a failing test."

Cucumber features plain text "stories" that are pretty awesome for getting some really concrete tests up & running. Maybe that would be one place where you could get started. Cucumber doesn't really work with an AJAX-based app though, for that you'd have to take Selenium or Watir instead. You can start with a failing story before writing a single line of code, and quickly proceed from there to make that story pass.

"Don't test, specify."

Instead of thinking of tests, try to make a mental switch: you're not testing but SPECIFYING how your application will behave. This is design work, not nearly as boring as testing. :)

Pirkka Hartikainen
A: 

Well I'll tell you how!

FIRST DO THE FOLLOWING 10 TIMES MANUALLY ON DIFFERENT APPLICATIONS ,BEFORE YOU TRY TO AUTOMATE

the negative scenarios, where the result would come out negative. it could be wrong data entered and gives you right outputs.

for example a login screen: There could be many scenarios when correct User wrong PW,Wrong User correct PW.... the most important thing is YOU DONT GIVE UP UNLESS BREAK IT .this is your mantra.

HMMM NOW YOU ARE THINKING LIKE A TESTER NOW TURN TO UR SYSTEM, JUS WRITE THE NEGATIVES TESTS AND THEIR RESULTS AND THEM THE POSITVE TESTS DESIGN IT. NOW DEVELOP THE FRAMEWORK

Ayreej
+1  A: 

I wrote a motivation post about just this case couple of days ago. Here is the summary:

Start writing tests whenever you have an opportunity to do it (ie. whenever you write some code). Choose any tool that makes sense to you and write any test that you feel could cover at least some tiny behavior of your application (don’t care about the coverage or any other scary terms from the day one). Don’t be afraid about primitive tests and trivial assertions - you’ll get more confidence as your test coverage will grow and you’ll become more and more happier as you’ll notice that you don’t need to hit F5 that often anymore. Think about testing in other positive terms - the better you are at it, the less time you need to spend with activities you don’t like (watching the spinning refresh icon in the browser, debugging) and more with things you love.

And here is the whole thing, if you are interested.

Milan Novota
+1  A: 

As has been mentioned previously, the easiest way to break into testing is with regression testing.

I'd also avoid doing controller specs - they are a PITA. Do heavy model testing, because that's where the logic should be in the first place.

Try spec'ing / testing a plain ruby project before you go off into a rails project.

A: 

Ask a better question get a better answer...

How can I test can have fun doing it and acheive my objectives?

yeah, asking a better question is a cheap motivational speaker trick, but it works pretty well

iterationx