Topic: whats it all about.

Do I need to do it. perhaps i'm a little bit of a simpleton. or maybe just stuck in my ways. but what are the advantages in testing?
you're going to manually do it any way? who builds a site then does'nt use it, before giving it to the customer.

could somebody give an example on how testing is better than just using the app. surely it just increases your chances of an error?

Last edited by BasicMind (2006-11-19 13:47:33)


Re: whats it all about.

It's true that using an application is an excellent way to test it, but automated tests that you write at the same time as writing code are far better.

If you have a large application that is full of tests then you can be reasonably sure it's working the way you want.  Then, when you need to fix a small bug or add a new feature, you can run all the tests and see if you accidentally broke any part of the application.  If you don't have to do the tests, you'd have to manually check every part of your application every time you made any change.  Once your application gets large it could take you DAYS to test it by hand.

If you've every made an application that doesn't have tests and gets really big you'll know that you can't touch it without possibly breaking something.

Re: whats it all about.

I supose. I have never built a massive app before. so doing it as I go has never been a problem. I just got a new book, "beginning ruby n rails e-commerce" and the whole books is about building a site with testing from the start. finding it hard to get my head around it.


Re: whats it all about.

I was never a fan of TDD when I used it with Java but in RoR it's great. 

Apart from the obvious advantage of being able to see if your app breaks after you've made a little change elsewhere, it also makes you really think about HOW and WHY you've coded something in a certain way.  Or if you're writing your tests before your code HOW and WHY you're thinking about coding in a certain way.

Last edited by brae (2006-12-06 12:09:42)

Re: whats it all about.

I am wondering what to test, I can understand modeltesting, but how to test a view for example. It would take twice the code to just test it, and how about if it is multilangual, that would be like, impossible or something.

Last edited by Moofius (2006-12-10 15:34:19)

Re: whats it all about.

I don't think extensively testing the view is necessary. Most logic should be kept out of the view so it's not really doing much more than presentation. I also want the view to be flexible and not break any tests when I'm changing the layout.

However, you can't keep all logic out of the view. Sometimes you need to display a certain element in certain conditions. This is something that would be a reasonable test.

The concept of a multilangual site is a good one. In a way it is easier to see what should and should not be tested. The natural language in the view should not be tested because it is too restricting. Something like the wording in the paragraph should be changable without failing tests. If you do need to test whether something is visible or not, use the name/id of an HTML element instead of the natural language inside the element.

That said, the amount of testing is largely dependent upon the project. It's a balancing act between having good test coverage while keeping the flexibility. A good rule of thumb to go by is: if changing something doesn't break the application, but it fails a test, then you have too much test coverage. On the other hand, if you can change something to break the application, and all tests still pass, then you need better test coverage.

Railscasts - Free Ruby on Rails Screencasts

Re: whats it all about.

My program has gotten to a certain size where I can no longer easily change something and then test through the browser.

Last week I re-factored a function, and because of a typo I introduced a bug that I did not notice until a couple of days ago while working to add functionality in the same part of the program. When I saw the bug I assumed I had introduced it within the last few moments but could not figure it out, so I reverted that particular file from the subversion repository. I was stressing out a bit when that didn't fix it!

Anyway, I am now going back to put all of my testing in place, but I really wish I had done it from the beginning. Hopefully it won't take too long.