There are some environment compatibility issues with the version this article is about, 0.1.0: - only compatible with Rails 2.2.0, - assumes that the "test" directory is present in the load path, - assumes that RubyGems is loaded by the time test_heper.rb is evaluated, which is very unlikely on most systems.
I apologize for these issues. Thanks to Justin Ko for reporting them! Version 0.1.1 will fix them, and I'll announce its release in a new article.
Matt Lins
· 1 year ago
Cool, I just ran into the same problems.
Can't wait for 0.1.1!
Roman2K
· 1 year ago
v0.1.1 is out, the article has been updated to reflect the changes.
Roman2K
· 1 year ago
New update of the article: added a note (including the fix) about an error I have encountered several times when running tests from TextMate.
drnic
· 1 year ago
We needed to create tmp/sockets first, before the server started. Perhaps run FileUtils.mkdir_p "tmp/sockets" in the server code?
We're getting this working from the root folder of the app, within the terminal, but its not running the test in the server from the following scenarios:
* Cmd+R from TextMate when viewing the test file * ruby units/user_test.rb -> from the test folder itself - that is, if we're not in the root folder it fails.
We tried manually hacking the ENV['RUBYLIB'] at the top of the test_helper.rb to explicitly add the full path to the test folder, but it doesn't seem to help.
Thanks! I'm testing that patch, having a weird error at the moment. Working on it.
Roman2K
· 1 year ago
I don't understand why Cmd+R doesn't work from TextMate. Have you added "test" in $RUBYLIB in your ~/.bash_login?
Hacking ENV['RUBYLIB'] at the top of test/test_helper.rb can't work since it's only used by the intepreter before trying to load the file.
Dante Regis
· 1 year ago
I can make it work on the command line, but not on Textmate. I'm using the bundle from the github. Any thoughts?
drnic
· 1 year ago
Try using chendo's fork and see if it helps?
Roman2K
· 1 year ago
Yes that, or try clicking the "i" spot in the bottom left or bottom right corner of the project drawer, and add the variable "RUBYLIB" with a value of ".:test" (dot, colon, "test"). It works, then add that variable to ~/.bash_login, otherwise the change won't persist across TextMate sessions.
Are you sure it does? I don't see how it could from the diff.
August Lilleaas
· 1 year ago
How are you people able to run the tests directly from textmate, without doing load path shizzle? Aren't you using 2.1 yet? Cause in 2.1, the reuire 'test_helper' part is now depending on having Rails.root/test in the load path.
Roman2K
· 1 year ago
Hi August. Actually I was using it with 2.2.0 only untiI got feedback. Reading your comment, I realized that I had modified a file in TextMate.app a while ago to make it support relative requires of "test_helper". I'm updating the article right now. Thanks!
chendo
· 1 year ago
Don't use my fork yet... turns out it's got some issues (it was requiring the wrong gem so it might not have been working properly).
Also ran into issues with clean_up_app nuking machinist blueprints, but should have a solution soon.
This article has been updated once again to include that fix. Only step 3 was modified.
Thank you for the feedback so far! Hang in there, it's worth it.
chendo
· 1 year ago
Sorry Roman2K, the commit we posted actually didn't work (service_uri was returning the mkdir_p, which was tmp/sockets and not the actual file).
This commit (http://github.com/chendo/rails-test-serving/com...) works and also fixes the machinist problem we were having, where the first test would run, but any after that would error saying 'no blueprint for Foo'.
This fork solves it by adding a TEST_SERVER_OPTIONS constant that you define before you require 'rails-test-serving'.
The 'unless defined' part is there to stop the warnings.
This forces any required files that match /blueprint/ to be reloaded.
Also my fork allows you to run tests when not in RAILS_ROOT, since the SERVICE_URI in Roman2K's branch is relative to the current directory. Our fork currently looks up three directories (three because the test folder shouldn't be any deeper than that) to find config/boot.rb, then adds tmp/sockets/test_server.socket to that path.
This is awesome and hopefully our fork has made it even more awesome.
P.S. Shouldn't it be called 'rails-test-server'?
Roman2K
· 1 year ago
Thanks chendo!
How about $test_server_options instead? That would avoid warnings and allow for ||= {} in Server#initialize.
I like the lookup for the root directory. However, I will make it more generic (infinite depth) because in my code, each namespace has a corresponding directory in both app/models and test/units.
About the name "RailsTestServing", I agree it's not ideal. "RailsTestServer" came to mind, but since it's a container for a Client and a Server class, Server would end up having a full name of RailsTestServer::Server which I don't like.
Thanks Roman - we're so in love with the <1s Cmd+Shift+R times.
Roman2K
· 1 year ago
You're welcome, drnic! (Sorry for the late reply.)
Jeff
· 1 year ago
Great idea. Things work for me on the first pass, but fail the second time around. Running 0.1.3. Not looking for you to solve my problem, but can you think of why I don't seem to have a transaction the second time around? Running Postgres.
** Test server started (#38293) >> test/unit/patient_test.rb (5366 ms) >> test/unit/patient_test.rbNOTICE: there is no transaction in progress
Roman2K
· 1 year ago
Hi Jeff. I will look into your problem. Thanks!
Roman2K
· 1 year ago
Hi Jeff. Sorry, I wasn't able to determine the cause of this error related to PostgreSQL transactions. Have you made any progress on the subject?
nirvdrum
· 1 year ago
Hi,
Like Jeff, I can't get my tests to run more than the first time. I get an exception about a class not being defined:
LoadError: Expected /Users/kmenard/dev/workspaces/sml/lib/maui/bad_words.rb to define Maui::BadWords
That file does indeed define the class BadWords in the Maui module. I'm not really sure what's going on there. Please let me know if you need any additional info.
Roman2K
· 1 year ago
Hi Kevin,
Is "Maui" the exact letter case of the module? I ask because with ActiveSupport::Dependencies, if FOO::Bar is evaluated before FOO, FOO will be looked for in foo.rb and loaded, but then FOO::Bar won't be found since it will expect foo/bar.rb to define Foo::Bar instead.
Could you please give me the output the following chunk of code, put at the top of maui/bad_words.rb p ActiveSupport::Dependencies.autoloaded_constants.grep(/maui/i) p ActiveSupport::Dependencies.loaded.grep(/word/)
Or better, let's solve this together on IRC if you want. I'm in Freenode #rubyonrails, as Roman2K.
Roman2K
· 1 year ago
Kevin and I worked it out together on IRC. The issue was related to ActiveSupport::Dependencies' lazy loading mechanism. In short, the solution was to create lib/maui.rb with an empty definition of Maui. That is:
# lib/maui.rb module Maui end
Then, AS::Dependencies was able to load and reload Maui::BadWords as expected between each test run. Thanks, Kevin!
Andy Triggs
· 11 months ago
Thanks for this, it looks great. However, we're having some issues. The server runs fine and picks up test runs, but provides no appreciable increase in speed on successive runs. Also, when running functional tests, I receive "A copy of ApplicationController has been removed from the module tree but is still active!" when running a test for the second time.
Roman2K
· 11 months ago
Hey Andy. What kind of durations does the server log show? Is it less than 1000ms or more? If it's less, maybe the runs are slow because they're run by both the server (fast) and the client (slow).
The error you get about ApplicationController might be related. Could you try the latest version from GitHub (see the commands at the bottom of the article) in combination with RailsDevelopmentBoost (http://github.com/Roman2K/rails-dev-boost/tree/... -- see the note in the "Usage" section) as it would make less constants be reloaded between consecutive runs, perhaps avoiding the error about ApplicationController.
If that doesn't work, try cd'ing into app/controllers and creating a symlink from application_controller.rb to application.rb.
Luke
· 10 months ago
Has anyone had any luck using this with Rails' rake tasks? With the server running, `rake test:units` just produces:
Started
Finished in 0.000236 seconds.
0 tests, 0 assertions, 0 failures, 0 errors
I'd much prefer to run the whole test suite at once.
Thanks in advance for any help! <3
Roman2K
· 10 months ago
When running tests from Rake tasks, test files are loaded from within the task of the client process, so RailsTestServing has no way to catch them beforehand in order to forward them to the server. Given that, the output you pasted is normal: the test:unit task loaded a test file that started the client which connected to the server, thinking it had test files to forward them, while in fact it didn't ("0 tests").
(At least for now,) only test files specified as an argument can be run by the server (like: ruby test/unit/foo_test.rb). To run more than one file, the server would have to be modified to load several files given their paths, a Dir.glob pattern, or a special argument. See RailsTestServing::Server#capture_test_result, inside the innermost block.
Or do you want the `rake test:units` to run tests on the client side instead? In that case, it's RailsTestServing::Client#run_tests! that should be altered, maybe checking the nature of $0 and the contents of ARGV before trying to connect to the server.
mwilliamschimp
· 8 months ago
Hello, late to the party here but running into difficulties! And I would LOVE to have this working and it's such a great tool!
Anyway, I opened an issue on your Github repo :). Essentially, my tests run fine the first time (though not very quickly) but the second time trying to run them, they fail completely; every single one of them. Have you seen this behavior before?
Edit: I just tried the test server on a smaller project and it's running just fine (with some faster test time). So I'm guessing it's something in my environment for the other project (which is a very large project). Hmmm, time to hack away I suppose!
Roman2K
· 8 months ago
Hey Matthew.
I appreciate that you took the time to post a comment here *and* to open an issue on GitHub. I hadn't seen such a problem before.
I replied to your issue on GitHub: I think a full stack trace will bring enough information for me to fix this bug or help you make it work with your bigger project.
Jeff Cole
· 1 month ago
Hi, I just added a comment on GitHub. Essentially, we are seeing the same thing.
All Comments
- only compatible with Rails 2.2.0,
- assumes that the "test" directory is present in the load path,
- assumes that RubyGems is loaded by the time test_heper.rb is evaluated, which is very unlikely on most systems.
I apologize for these issues. Thanks to Justin Ko for reporting them! Version 0.1.1 will fix them, and I'll announce its release in a new article.
Can't wait for 0.1.1!
Too...lazy... to... make ...patch :)
* Cmd+R from TextMate when viewing the test file
* ruby units/user_test.rb -> from the test folder itself - that is, if we're not in the root folder it fails.
We tried manually hacking the ENV['RUBYLIB'] at the top of the test_helper.rb to explicitly add the full path to the test folder, but it doesn't seem to help.
Thoughts?
http://github.com/chendo/rails-test-serving/com...
Hacking ENV['RUBYLIB'] at the top of test/test_helper.rb can't work since it's only used by the intepreter before trying to load the file.
Also ran into issues with clean_up_app nuking machinist blueprints, but should have a solution soon.
http://roman.flucti.com/textmate-fix-for-relati...
This article has been updated once again to include that fix. Only step 3 was modified.
Thank you for the feedback so far! Hang in there, it's worth it.
This commit (http://github.com/chendo/rails-test-serving/com...) works and also fixes the machinist problem we were having, where the first test would run, but any after that would error saying 'no blueprint for Foo'.
This fork solves it by adding a TEST_SERVER_OPTIONS constant that you define before you require 'rails-test-serving'.
Example:
TEST_SERVER_OPTIONS = {
:reload => [/blueprint/]
} unless defined? TEST_SERVER_OPTIONS
The 'unless defined' part is there to stop the warnings.
This forces any required files that match /blueprint/ to be reloaded.
Also my fork allows you to run tests when not in RAILS_ROOT, since the SERVICE_URI in Roman2K's branch is relative to the current directory. Our fork currently looks up three directories (three because the test folder shouldn't be any deeper than that) to find config/boot.rb, then adds tmp/sockets/test_server.socket to that path.
This is awesome and hopefully our fork has made it even more awesome.
P.S. Shouldn't it be called 'rails-test-server'?
How about $test_server_options instead? That would avoid warnings and allow for ||= {} in Server#initialize.
I like the lookup for the root directory. However, I will make it more generic (infinite depth) because in my code, each namespace has a corresponding directory in both app/models and test/units.
About the name "RailsTestServing", I agree it's not ideal. "RailsTestServer" came to mind, but since it's a container for a Client and a Server class, Server would end up having a full name of RailsTestServer::Server which I don't like.
Off to merging your fork :-)
** Test server started (#38293)
>> test/unit/patient_test.rb (5366 ms)
>> test/unit/patient_test.rbNOTICE: there is no transaction in progress
Like Jeff, I can't get my tests to run more than the first time. I get an exception about a class not being defined:
LoadError: Expected /Users/kmenard/dev/workspaces/sml/lib/maui/bad_words.rb to define Maui::BadWords
That file does indeed define the class BadWords in the Maui module. I'm not really sure what's going on there. Please let me know if you need any additional info.
Is "Maui" the exact letter case of the module? I ask because with ActiveSupport::Dependencies, if FOO::Bar is evaluated before FOO, FOO will be looked for in foo.rb and loaded, but then FOO::Bar won't be found since it will expect foo/bar.rb to define Foo::Bar instead.
Could you please give me the output the following chunk of code, put at the top of maui/bad_words.rb
p ActiveSupport::Dependencies.autoloaded_constants.grep(/maui/i)
p ActiveSupport::Dependencies.loaded.grep(/word/)
Or better, let's solve this together on IRC if you want. I'm in Freenode #rubyonrails, as Roman2K.
# lib/maui.rb
module Maui
end
Then, AS::Dependencies was able to load and reload Maui::BadWords as expected between each test run.
Thanks, Kevin!
The error you get about ApplicationController might be related. Could you try the latest version from GitHub (see the commands at the bottom of the article) in combination with RailsDevelopmentBoost (http://github.com/Roman2K/rails-dev-boost/tree/... -- see the note in the "Usage" section) as it would make less constants be reloaded between consecutive runs, perhaps avoiding the error about ApplicationController.
If that doesn't work, try cd'ing into app/controllers and creating a symlink from application_controller.rb to application.rb.
With the server running, `rake test:units` just produces:
Started
Finished in 0.000236 seconds.
0 tests, 0 assertions, 0 failures, 0 errors
I'd much prefer to run the whole test suite at once.
Thanks in advance for any help! <3
(At least for now,) only test files specified as an argument can be run by the server (like: ruby test/unit/foo_test.rb). To run more than one file, the server would have to be modified to load several files given their paths, a Dir.glob pattern, or a special argument. See RailsTestServing::Server#capture_test_result, inside the innermost block.
Or do you want the `rake test:units` to run tests on the client side instead? In that case, it's RailsTestServing::Client#run_tests! that should be altered, maybe checking the nature of $0 and the contents of ARGV before trying to connect to the server.
Anyway, I opened an issue on your Github repo :). Essentially, my tests run fine the first time (though not very quickly) but the second time trying to run them, they fail completely; every single one of them. Have you seen this behavior before?
Edit: I just tried the test server on a smaller project and it's running just fine (with some faster test time). So I'm guessing it's something in my environment for the other project (which is a very large project). Hmmm, time to hack away I suppose!
I appreciate that you took the time to post a comment here *and* to open an issue on GitHub. I hadn't seen such a problem before.
I replied to your issue on GitHub: I think a full stack trace will bring enough information for me to fix this bug or help you make it work with your bigger project.