I'm a PHP dev mostly and just starting out with Ruby, so please correct me if I say something dumb.
I'm working on fixing some bugs in a "legacy" app written in rails. The app itself has never been unit-tested. I can see the test scaffolding generated by rails but tests are nowhere to be found.
The app is pretty big and the code quality is very bad, so I wanted to write some units tests for the functionality I'll be fixing, before writing any code.
The problem is that when I run rake test command, the testing DB is created, but if I write any tests it keeps crashing on me. There are several problems with some relations and keys which I tried to fix, but more problems just keep appearing. I do understand that the DB is created with schema.rb file, but I'm sure it is just outdated by now. It is another issue I will maybe fix, but for now I just want to write some basic unit tests not even using the DB itself.
So the question is: is it possible to write just unit tests for some methods without invoking all the test DB scripts? I'm aware that this is maybe not the best practice, but I will feel better modifying the app with some test coverage and starting with fixing the DB I do not yet understand seems like a bad idea to me.
I'm using Ruby version 2.1.10 and the app is written in Rails 4.0.4 - these seem to be the latest versions I managed to run the app on.
Related
In my rails application, I have 2000 lines of code for cucumber features.
Now I am running all of the features at once using command rake rcov:features for getting coverage report.
I observed that while running all at once, they hang at some of the features and, because of this, are not generating the coverage report.
Please suggest, what are the possibilities of getting hanged?
I've seen this happen when the code depended on modernizer, and it was removed. I have also seen this happen when an incompatible/unbuildable server is specified in the gemfile (in this case, a broken build of thin on Windows). I have also seen machines with issues using selenium, and none using capybara-webkit, and vice-versa. Basically, there are about a million things that can go wrong, it seems to me that rails testing in general will benefit from additional polish and improved interaction. I wonder if you would have an easier time starting off small, instead of trying to find out exactly where in the 2000 lines it is all at once, perhaps it would be easier to remove all but a little bit of the code, and add it in slowly, until something fails. You could do the same thing, using your git repo, if this has worked in the past. Break it up into a smaller, simper, and more digestible project.
For testing purposes for Ruby/Rails I use RSpec and I have well over 1000 tests that are already written in my application. Once the app goes live I want to have the tests run once a day on the production server (since all the code is there) and see if anything fails. The test itself will be run against test data and now production data. This is an effort so that any new code that is added in the future will not cause anything to unknowingly break.
I have found a few solutions:
Travis-CI (only open-source ... not suitable for closed-source projects)
Jenkins-CI (not sure if it works with or well with Ruby/RSpec/Rails)
Watir (not sure if Ruby/Rspec works with it, but the tool itself is written in Ruby).
Preferably something that checks the codebase daily and then emails me when something isn't working.
I also plan on integrating JavaScript testing with the a testing library of my choice (I just need the automation platform for testing it).
Can someone provide me some insight as to which tool to use? Or does anyone have any other tools to recommend?
Jenkins-CI works great with rspec, and can run your jasmine javascript testing, and your cucumber javascript tests as well.
The only thing I'd recommend is not to test on your production server itself. When you push changes to your source-control repository, Jenkins will download the new code and run your tests there. When you're green (tests pass), push the code to production.
I have an existing Rails app that I built using Rails 3, Mongoid/Mongodb and Devise. The app is running fine. I'd now like to add some tests to it (sure, shoulda done this in the beginning but the learning curve for just Rails was enough...).
I've used several pages to get it going, especially the Rails guide and this blog post about Mongo and Cucumber/Rspec. My concern here is that between all of the "add this to this and such file" that I've done to try and get this working (and it's not) I've made such a mess of things that it might be better to start over from scratch. With the testing portion of the app.
I thought I would just delete the spec and test directories and re-gen the tests but I can't find a command to do that (the regen).
I've built a very simple test (assert true) but I'm getting:
D:/Dev/TheApp/test/test_helper.rb:10:in `<class:TestCase>':
undefined method `fixtures' for ActiveSupport::TestCase:Class (NoMethodError)
I think the real issue here is that I'm using MongoDb and the test architecture in Rails seems to really really want to do ActiveRecord. Not sure if those two are compatible.
Is there a quick way to build a barebones test directory? My short term solution is to just roll back those directories. Hoping for a better solution.
The blank tests are really worthless. If you didn't have tests/specs of value, then just start from scratch. And if you want to start over, you should just delete them and start new.
You could treat your code as "legacy code" as defined by Michael Feathers in Working Effectively with Legacy Code -- that is, code without tests.
Take a look at this getting started with rails testing guide over at 10gen:
http://www.mongodb.org/display/DOCS/Rails+-+Getting+Started#Rails-GettingStarted-Testing
We've recently upgraded our Rails application.
To be extra sure everything works, I've tried to get the tests and specs of the various used plugins (26 at current count) to work, thinking then to add those to our continuous integration, which only runs the main application's specs.
I've run into a lot of problems even getting the specs/tests to run at all, not even getting to any individual test failures. For example, I've run across this problem: http://rails_security.lighthouseapp.com/projects/15332/tickets/7-rake-spec-plugin-fails-on-rails-2-1 (thanks by the way for that ticket, even though the issue wasn't fixed).
So the question is: Are we unusual in that we've ever cared about running plugin tests ? It doesn't seem to feature much here on SO. My nagging feeling is that they should be run as much as the main specs, but you could also argue that since the main specs work, the plugins must also work.
Alot of it depends on the plugin/gem being used.
If I know the author/community of the gem is competant I will skip the tests and simply use the latest stable release and freeze that gem. I will then track the progress of the development using github.
If the plugin/gem is written by an unknown party I will run the tests and freeze the gem/plugin and again monitor the development.
Sometimes however I will write my own contributions to the gem and fork the code. I will clone the repo in github and base my installations from that. At which point any and all changes result in a complete test run.
With all things in the open source world there is an element of trust between the creator and the users of those pieces of code. The tests themselves don't tell me much about the codebase, it shows there are tests and thats it. Do they test everything ? Are there edge cases ? . Its this element of trust I have with certain developers in the community that means I forgo worrying over running tests for those gems.
Its a slippery slope testing everything, where does it stop ? Would you test rails every release ? No, you assume the community has done this for you already.
Is it even worth it?
I'm working on assessing a legacy code base for a client -- the source code has been largely untouched since 2007 and it's built with Rails 1.2.3.
My Rails experience began at version 2.1 -- the code is fairly stock/scaffold like and devoid of meaningful tests -- I was curious to even see if I could get it running locally -- but, I'm not even sure where to start. Right off it doesn't even know what 'rake db:create' means. Ha!
Is it going be a major pain to even getting it running in 2.3.5? Should I bother?
Would love to hear your thoughts.
Thanks
If you're going to be actively developing the site, then yes, it is worth sinking the time into the project to bring it up to date. A lot has happened since Rails 1.2 which will make development a much more pleasant experience. Life without named scopes or RESTful resources is really difficult. If you're just patching the odd thing here and there, it may be worth leaving it mostly as-is and just dealing with the eccentricities.
Since 1.2.3 is just prior to the releases building up to 2.0 where a lot of warnings and deprecation notices were introduced, you could have quite a chore.
Some things to keep an eye out for:
Migrations are now date-tagged, not numbered, but are at least backwards compatible
Many vendor/plugins may not work, have no 2.x compatible version, or need to be upgraded
The routing engine has changed, and the name of many routes may have changed, so see what rake:routes says and get ready for a lot of search-and-replace
I did this for a client with a smallish site. First, version control is your friend. Make sure you have the entire codebase committed.
Next, the basic recipe is as follows
Tag the current source
Update to the next release of rails (you'll have to google for the release announcement). My app was frozen, so I just had to freeze to that version
rake rails:update to update the config, scripts and js
Diff your working copy against the version in your scm. Make any changes necessary for the app
Update any gems/plugins if necessary
Start the app, exercise and test. Look for deprecation notices
When it all looks good, commit to scm and tag
Lather, rinse, repeat
For my client's app, it was much easier than I thought.