Rails core - Feb 2014 - Allow bare CoffeeScript compilation to make it possible to test private functions

I was reading this old issue: https://github.com/rails/rails/issues/1125

The only proposed workaround in that thread is to globally enable bare 
mode always.

I use oojspec (a gem based on rails-sandbox-assets gem that will allow 
me to reuse my assets with sprockets requires support) to test my 
client-side code.

Sometimes it would be useful if I could test private functions in my assets.

An option would be to export them using some kind of convention, like 
prefixing private functions with underscore in some namespace so that I 
could access them from tests, but I'd prefer to do something like this 
instead in some cases:

http://philipwalton.com/articles/how-to-unit-test-private-functions-in-javascript/

The idea is to include the private function in the same scope as your 
test suite so that you're able to call them, only in that test context.

Also, while doing that, I'm not interested in private functions defined 
in other files than the one I'm interested in for the test suite 
purpose. So, a global bare approach is not only undesirable but could 
also lead to conflicts, which is dangerous.

Here's an example for creating a pagination bar:

pagination.js.coffee

#= require views/pagination-links

@buildPaginationLinks = (currentPage, lastPage) ->
   pages = createSelectablePages currentPage, lastPage
   JST['views/pagination-links'](currentPage, pages)

createSelectablePages = (currentPage, lastPage) ->
   # code I want to test separately


So, an ugly option currently would be adding something like this to the 
end of this file for testing purposes:

@buildPaginationLinks.createSelectablePages = createSelectablePages

Or exporting it to any other place where I would be able to access it 
from my tests, but by doing so it will be also accessible in the 
production environment. Not really a big deal, but I would be much 
happier if I could simply call "createSelectablePages" from my test 
suite and only from there. Maybe something like:

pagination_spec.js.coffee

#= require pagination, bare: true

describe "pagination", ->
   @example "createSelectablePages", ->
      @expect(createSelectablePages(2, 30)).toEq [1, 2, 3, 4, 5, 6, 30] 
# an ellipsis ("...") would be included between 6 and 30.
   # other test cases

Another option I'm considering is adding something like "#= require 
spec_helper" in the first line (actually I already have this in my 
specs), and adding something like "@testingScope = {}" to it (actually
I
use the "g" as a global namespace instead of the window, so it would 
read like "g.testingScope = {}" in my specific application). This way,
I'd be able to do something like 
"@testingScope.paginationCreateSelectablePages = createSelectablePages 
if @testingScope?". This is better but if I could convince you to 
reconsider adding support for defining the bare mode per file I'd be 
much happier.

In that old issue, it was asked what should happen in case two assets 
require the same file, one of them asking for bare while the other not. 
I believe raising an error would be fine in such situation, as it should 
work like embedding the required asset inside that one scope (function).

Maybe another option would be to create a new helper to aid with such 
cases. Instead of "require" we could call "embed" instead.
Then there's
no need to handle the above mentioned problem as the solution would be 
simple. "embed" will always embed the content (pre-compilation 
concatenation step, similar to C pre-compile directives/macros). If you 
do it more than once you'll have the code duplicated in different 
scopes/functions, but then it's the developer's choice and not a bug.

Would it be possible for you to reconsider this feature request with the 
testing use case in mind?

Thanks in advance,
Rodrigo.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.