# RE: The Guilt List **URL:** \ **Category:** Rails\ **Created:** [January 12, 2006, 9:42pm UTC](https://www.ruby-forum.com/t/re-the-guilt-list/95099 "2006-01-12T21:42:44Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![HoganS\_Brian\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de0a6/32.png) [@HoganS\_Brian\_P](https://www.ruby-forum.com/u/HoganS_Brian_P)\ **Post date:** [January 12, 2006, 9:42pm UTC](https://www.ruby-forum.com/t/re-the-guilt-list/95099/1 "2006-01-12T21:42:44Z")
I just started doing unit tests on my current application because I felt bad šŸ™‚ Iā€™ll figure out functional tests on the next app šŸ™‚ ---
**Author:** ![HoganS\_Brian\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de0a6/32.png) [@HoganS\_Brian\_P](https://www.ruby-forum.com/u/HoganS_Brian_P)\ **Post date:** [January 12, 2006, 9:51pm UTC](https://www.ruby-forum.com/t/re-the-guilt-list/95099/2 "2006-01-12T21:51:54Z")
The only guilt I feel in my rails aps is that I now have the time to do things right, including tests, and can bill for the whole thing. With PHP I used to take short cuts and cheat here and there because that is what the clients expected. They wanted something to work in the shortest amount of time possible. Clients still want that, but with Rails, I can indulge in the guilty pleasure of testing first, and still get the job done ahead of schedule. ## The truth be told, test driven development is actually faster than code reload, so Iā€™m not sure if it is Rails, Tests, or both that have allowed my my guilty pleasure. But Iā€™ll give credit to Rails because it makes testing so blasted easy. matt ---
**Author:** ![HoganS\_Brian\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de0a6/32.png) [@HoganS\_Brian\_P](https://www.ruby-forum.com/u/HoganS_Brian_P)\ **Post date:** [January 12, 2006, 9:54pm UTC](https://www.ruby-forum.com/t/re-the-guilt-list/95099/3 "2006-01-12T21:54:55Z")
Actually, this is one of the problems with the concept of ā€˜testingā€™ which implies that the functionality is completed and therefore just needs verification that it works as programmed. However, testing for is not about finding the gaps in my program it is able fleshing out the requirements of the design in a flexible forgiving structure. Good testing is about testing assumptions of the domain model as much as it is about testing the technical implementations. As an example, try this exercise with a small portion of your application. Before you dive into the model and the controller and the view, start writing assumptions you are making about how the application ā€œshouldā€ perform. Lets say we have a User model that needs to manage articles and images. Before I have written anything in my model I start brainstorming requirements in my unit tests test\_user\_create\_image test\_user\_destroy\_image test\_user\_cannot\_destroy\_others\_images test\_user\_can\_relase\_ownership\_of\_image test\_user\_update test\_user\_create etc.etc. etc. Immediately, I can start to plan out my application, is it smart to allow the user to create an image from inside the user model? Should it be abstracted into its own image model instead? These questions are easy to answer in tests because the code base is at its most flexible stage. It would be much harder to abstract these relationships when you have a controller and view tied to the assumptions you made about your domainā€¦ Anyway that is my two cents. Mark On 1/12/06, Hogan, Brian P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > * * * > > Rails mailing list > removed\_email\_address@domain.invalid > [http://lists.rubyonrails.org/mailman/listinfo/rails](http://lists.rubyonrails.org/mailman/listinfo/rails) > > * * * > > Rails mailing list > removed\_email\_address@domain.invalid > [http://lists.rubyonrails.org/mailman/listinfo/rails](http://lists.rubyonrails.org/mailman/listinfo/rails) ā€“