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.
Related
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 6 years ago.
Improve this question
I taught myself how to code and started building an app. I finished the app's basic structure but when I began I did NOT see the value in test. I didnt get it. Now I COMPLETELY see the value in test.
My question is how can I go back to early github commits and branch off of those and write test at that point in time and then add that test back into my main finished project? That way I can go slowly step-by-step vs. being overwhelmed with how many test I did not write.
Also, I can make sure I cover each area to test?
Any thoughts and how do I do this without screwing up even worse?!
-EDIT-
the reason I want to do it this way instead of just writing test is because when I try and use rspec I am getting errors on 3rd party gems. I want to write test before those gems were installed and figure out my issues from there. If that makes sense.
I would start by writing very basic tests first. And then slowly add tests for main features of your app. You should start writing test on your "develop" branch. You are doing the right thing and do not get intimidated by the amount of work. Slowly and steadily you can achieve this goal.
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 7 years ago.
Improve this question
I have code completed a project almost 50%, but haven't written any test code. I want to write rspec, capybara tests. Now this is reverse of what actually is done in testing. What should be my strategy here from where should I start (from model, controller, feature) and what should be my approach. Also are there any tutorials for this
Usually it's better to start from feature tests. They are easier to write and they provide most of coverage because cover a lot of functionality at once.
Also you will need not so many feature tests comparing to unit tests, for example. Because they are on top of the Testing Pyramid
When you will achieve decent coverage you can start throwing in unit test and refactor your codebase. Having feature tests you can eliminate the fear of refactoring. As soon as you haven't write test before the code your methods would be probably hard to test without additional refactoring.
That's is an additional advantage of having feature tests before unit tests.
You can find bunch of articles describing how do people usually test their projects.
As an example here is an article from Thoughtbot https://robots.thoughtbot.com/how-we-test-rails-applications
I would also recommend the Working Effectively with Legacy Code book.
It describes how to start covering projects with tests and then refactor the parts.
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
The title says it all, if I test using capybara :
visit this page
expect this content
and do this for every single feature(e.g signin, signup, search, clicking all the links and buttons, etc), would that be enough? Why would I need to test controllers and models? If features are working as expected, doesn't that mean everything is working in harmony?
That technique is called black box testing also know as functional testing. If you are testing as if you are a user of the application it is considered black box. If you are testing it from within it is considered glass box testing.
The question of whether or not is it enough is a matter of personal opinion. My opinion is if it is thorough enough then yes it could be enough.
Some of the advantages of black-box testing include:
You have a good chance of writing tests that weren’t imagined by the programmer.
The environment the program is running is also tested
The invested effort can be used multiple times
Some advantages of glass-box testing include:
It forces you to reason carefully about implementation.
Spots the Dead Code or other issues with respect to best programming practices.
Reveals errors in hidden code.
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.