Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am making my first RoR application and I am a bit confused with planning it out ahead of time.
It will be an anonymous imageboard (like 4chan) where people can make threads across multiple boards and attach images to their posts. They won't need to register and can post anonymously.
Now I am not sure how to implement it, I am guessing there has to be an admin user who will be able to create new boards and delete threads, right? So far I have planned the following controllers:
PostsController
UsersController (can I define the admin user here or should I make a separate controller?)
ThreadsController
BoardsController
Does this seem okay to you?
Thank you for your time.
Planning ahead of time for everything you will need goes against what Ruby on Rails philosophy is to begin with. Ruby on Rails firmly believes in Test Driven Development or TDD.
In that sense, the tests will actually drive your design, starting from unit tests all the way to functional testing. I.e. don't try to anticipate all controller/models from the start. Try to use TDD to let you help design the system, it is a good practice and if you don't know 100% the path you want to follow, it will help you somewhat make your system a bit more robust because of the test harness.
Try to follow this before you start your application. Good luck.
http://guides.rubyonrails.org/testing.html
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I joined a startup where my boss, so called Technology Head with 3 years experience has written the code and the website is running, She doesnt know testing and things are breaking apart now.
I have been Following TDD in my life, now I dont know how to test the RAILS APPLICATION where 50k LOC has already been written, waste code has piled up and there is no proper flow of the code at all.
How can I unit test the existing modules?
How can I refactor the maximum code with Test After Development approach for the existing code?
I am going bonkers with the existing code.
Cant make it again, not sufficient freedom to make it again.
Thanks in advcance
You could write a book on this subject (in fact I belive Mike Gunderloy did - Rails Rescue Handbook - though I can't seem to find a place to get it online now).
The short story is:
Unfortunately, it doesn't make business sense to retrospectively write tests for everything in the existing code base if it's basically working, so don't do that.
Start always writing tests for new features, and insisting others do too.
Whenever something in the existing codebase breaks, be sure to write a regression test.
When you make significant changes in the existing codebase, if it makes sense, add tests at the same time. Don't bother adding tests for small changes that can be easily manually verified; it likely isn't worth the time.
You probably already knew all that though. Good luck!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm very new to rails and have been following Ruby on Rails Tutorial book by Michael Hartl these days. I feel like testing is a really important thing for developing rails applications since the testing part covers about half of the entire book. But the more I read the book the more overwhelmed I felt about those code because sometimes I would have to spend so much time learning/ figuring out the test code before I can actually move on to the real code for the application. So my question is, is it really necessary to learn rails and its testing at the same time or it is okay for me to learn the rails basics first and maybe buy a rails testing book to learn it in particular after I get familiar with everything about rails so that I will not be too overwhelmed and I could spend more time focusing on the features using rails. Thanks!
Actually, the book itself answers your question:
It’s important to understand that TDD is not always the right tool for
the job: there’s no reason to dogmatically insist that tests always
should be written first, that they should cover every single feature,
or that there should necessarily be any tests at all. For example,
when you aren’t at all sure how to solve a given programming problem,
it’s often useful to skip the tests and write only application code,
just to get a sense of what the solution will look like. (In the
language of Extreme Programming (XP), this exploratory step is called
a spike.) Once you see the general shape of the solution, you can then
use TDD to implement a more polished version.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm about to start building a Rails app that will eventually need to vary CRUD access by user (i.e. which pages do they see, which can they edit, etc).
Is there a best stage of the development cycle to incorporate this?
Part of me feels like it should be the very first thing, since almost every piece of the interface will in some way rely on checking the user's ID, and it will be an inherent part of the DB structure.
Another part feels that this would overcomplicate things to start out with, and that I should instead build the core parts of the app, then layer on the authentication/authorization later.
Are there any best practices around this sort of thing?
I would say that if your system will rely on some kind of authentication... Why wait?
Let's say that you start developing your application without the authentication layer but at the same time you know that at some point you will have to do it. That means that at some point you will develop the authentication layer, and most likely you will have to refactor what you have already built to adapt it to this new layer.
Also, to try to convince you a little bit more...When you say:
I should instead build the core parts of the app
You should consider that the authentication module might be a core part of the app too...
I prefer to do it early, but you really have roughly the same amount of work in front of you regardless of when you do it. It really a matter of opinion on when you prefer to do it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
This app had virtually no tests in place when we came to it and now there are cucumber tests covering the most essential parts. We are not sure if the app is working correctly and have had many disasters happen over the course of development, most of them caused by bugs that were never discovered. The code is quite ugly in places with models generating HTML and PHP-itis in the views. There are many extraneous models and controllers that could be greatly simplified or eliminated. My question is, when is it better to simply refactor code without testing previous functionality? Due to deadline constraints, it's very hard to justify spending time on covering all the existing code with tests when we know it's bad and could be easily eliminated.
I'm gonna guess this is a client project. My approach would be to write Cucumber tests to cover the behavior of the project only, and then write RSpec implementation tests that cover the new code you'll be writing.
Get the client to sign off on the behavior tests, this way, when you start changing the implementation, you can be sure you haven't drastically modified the behavior of the app. Then, write the tests for the code you wish you had, and refactor until the tests are all green.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am on a tight timeline with minimum resources for a project.
I would like to practice test driven development for this project, but realistically, i would not have time to learn any of the more sophisticated frameworks like Cucumber, Rspec, etc. And it would probably be counter-productive at this point anyway
What do you recommend is the minimum I do?
If you are very short on time, your best bet would be to read through the rails guide on testing. It equips you to get started quickly with Test:Unit.
Then you could write unit tests for the (model) methods that you care most about - things most critical to your app.
Optional suggestion - Rails testing is a landscape full of controversies and debates. If you want to save time, get started with (any) one thing (Test:Unit/shoulda/rspec...fixture/factory ..etc) and leave the discussions for leisure.
You might want to give Shoulda a try.
Test Unit is baked into rails and is pretty easy to use if you have any background with unit testing.