I've the follwoing test. For some reason the #$e I've set in the before function is undefined in the test:
assert = buster.assert
buster.testCase 'BaseChart',
before: ->
#el = sinon.spy()
#$el = [#el]
console.log(#$el)
##[LOG] [function spy() {}]
'updates when the model changed': ->
console.log(#$el)
##[LOG] undefined
This is a wild guess but change:
before: -> to before: =>
And see if that helps.
Related
That's my suspicion as this simple code
-module(simple_server).
-export( [sayHello/0] ).
-callback say(Num :: term()) -> term().
sayHello() ->
io:fwrite( "Hello 1: ~p\n", [ say(1) ]) ,
io:fwrite( "Hello 2: ~p\n", [ say(2) ]) .
fails to be compiled:
$ erlc simple_server.erl
simple_server.erl:7: function say/1 undefined
simple_server.erl:8: function say/1 undefined
If that is the case, then this is not explicitly commented elsewhere:
official docs, "learn erlang", this answer.
You need to provide the name of the callback module, which can be done through apply and spawn, but you can also make a simple call using a variable as the module name, e.g. CallbackModule:say(1).
So you could do either:
sayHello(CallbackModule) ->
io:fwrite( "Hello 1: ~p\n", [ CallbackModule:say(1) ]) ,
io:fwrite( "Hello 2: ~p\n", [ CallbackModule:say(2) ]) .
or
sayHello(CallbackModule) ->
io:fwrite( "Hello 1: ~p\n", [ apply(CallbackModule, say, [1]) ]) ,
io:fwrite( "Hello 2: ~p\n", [ apply(CallbackModule, say, [2]) ]) .
Those two versions are equivalent.
Let's create a callback module implementing the simple_server behaviour:
-module(my_callback).
-behaviour(simple_server).
-export([say/1]).
say(N) ->
{N, is, the, loneliest, number}.
Now we can call simple_server:sayHello with the module name as the argument:
> simple_server:sayHello(my_callback).
Hello 1: {1,is,the,loneliest,number}
Hello 2: {2,is,the,loneliest,number}
HOWTO Erlang Custom Behaviors (template method pattern).
-1. Write a generic module. Here, an algorithm is defined, but some steps (callback functions in Erlang nomenclature) are left for a future specific definition.
%% generic.erl
-module(generic).
-export( [sayHello/1] ).
-callback say(Num :: term()) -> term(). %% future definition
%% generic algorithm: needs the reference to the provider module
sayHello(ProviderModule) ->
io:fwrite( "Hello 1: ~p\n", [ ProviderModule:say(1) ]) ,
io:fwrite( "Hello 2: ~p\n", [ ProviderModule:say(2) ]) .
-2. Compile generic.erl
erlc generic.erl
-(3.) Try to write a provider (callback) module
%% callbacks1.erl (fails to implement say/1 callback)
-module( callbacks1 ).
-behaviour( generic ).
-(4.) Compile callbacks1.erl: use -pa . to say where generic.beam is. (Therefore, the expected warning about say/1 is issued).
erlc -pa . callbacks1.erl
callbacks1.erl:2: Warning: undefined callback function say/1 (behaviour 'generic')
(Note: If -pa is not given, you'll got this: "callbacks1.erl:2: Warning: behaviour generic undefined")
-3. Write a correct provider (callback) module.
%% callbacks2.erl
-module( callbacks2 ).
-behaviour( generic ).
-export( [say/1] ).
say(1) -> "good morning";
say(2) -> "bon jour";
say(_) -> "hi".
-4. Compile it
erlc -pa . callbacks2.erl
(Ok now).
-5. Write a main.erl to gather generic module with callback module.
%% main.erl
-module( main ).
-export( [main/0] ).
main() ->
%% call the generic algorithm telling it what callback module to use
generic:sayHello( callbacks2 )
. % ()
-6. Compile and run main
erlc main.erl
erl -noshell -s main main -s init stop
We get:
Hello 1: "good morning"
Hello 2: "bon jour"
I get the following error:
Uncaught TypeError: Cannot call method 'push' of undefined
In the next code:
class classDemo
names : ['t1', 't2']
methodM1: () ->
# This works:
#names.push 't3'
console.log #names.toString()
#socket = io.connect()
#socket.on 'connect', () ->
# This raise the error:
#names.push 't4'
console.log #names.toString()
Does anyone know how to push into "names" inside the socket.on method? (How to push 't4' correctly?
Thanks
EDIT: The solution proposed by #Sven works for one level of chaining. It seems to fail for two chained calls. Please consider the following example:
methodM1: () ->
_this = #
#socket = io.connect() # connect with no args does auto-discovery
#socket.on 'connect', () ->
# This works:
_this.names.push 'inside connect'
console.log _this.names.toString()
#socket.emit 'getModels', (data) ->
# This does not work:
_this.names.push 'inside emit'
console.log _this.names.toString()
I tried to apply the same solution again inside connect and before emit (see below) but I get no output:
_this2 = _this
#socket.emit 'getModels', (data) ->
_this2.names.push "inside emit"
console.log _this2.names.toString()
Thanks.
your emit is never fired because emit sends data and requieres therefore a datastructure.
Please change your code like this
a) use the fat arrow
b) emit a data structure
methodM1: ->
#socket = io.connect()
#here use the fat arrow it does the '_this = # automatically'
#socket.on 'connect', =>
#names.push 'inside connect'
console.log _this.names.toString()
#socket.emit 'getModels', yo: "got your message"
The fat arrow always binds to the outer instance (see When does the "fat arrow" (=>) bind to "this" instance)
I am not sure (well, I am pretty sure but havent tried it) that you can send a closure over the wire.
Folks,
Trying to figure out the difference between these 2 statements, and why one works, and the other throws an error:
works:
jsonFileContents = fs.readFileSync('sample.json', 'utf8')
res.send(jsonFileContents)
does not:
jsonFileContents = fs.readFileSync('sample.json', 'utf8')
returnResult(jsonFileContents)
returnResult = (data) ->
res.send data
error thrown:
`TypeError: undefined is not a function`
It's because returnResult is not defined upon usage.
The following should work:
returnResult = (data) ->
res.send data
jsonFileContents = fs.readFileSync('sample.json', 'utf8')
returnResult(jsonFileContents)
I try to write some simple tests in Coffeescript and Jasmine.
# greet.coffee
greet = (message, person) ->
"#{message}, #{person}!"
and here my Jasmine Spec File:
# greetSpec.coffee
describe 'greet', ->
it 'should greet with message and name', ->
result = greet 'Hello', 'John'
expect(result).toBe 'Hello, John!'
When i start SpecRunner in Jasmine i get:
ReferenceError: greet is not defined
I guess it has something to do with the namespace autogenerated by coffeescript and therefor is the greet function not visible from the Spec file. How can i solve it?
Ok, could solve it with a simple global variable (not sure if that's a good way, though):
greet.coffee:
#greet = (message, person) ->
"#{message}, #{person}!"
greetSpec.coffee:
describe 'greet', ->
it 'should greet with message and name', ->
result = greet 'Hello', 'John'
expect(result).toBe 'Hello, John!'
I have a controller which relies on a service built through ngResource. I am having trouble testing this(although both appear to work like a charm in the actual application). The following is the (sanitized) Controller
MyApp.Controller.MyCarsController = (scope, http, typeService) ->
if scope.context==undefined
scope.ferrari_or_porshe =""
scope.id = ""
else if scope.context=="ferrari"
scope.country_or_pi ="Ferrari"
else if scope.context=="porshe"
scope.country_or_pi ="Porshe"
typeService.index
ferrari_or_porshe: scope.ferrari_or_porshe
id: scope.id
, (response) ->
scope.type = response
scope.loading = false
MyApp.Controller.MyCarsController.$inject = ['$scope', '$http', 'Type']
And this is the Service:
MyApp.MyModule.factory 'Type', ['$resource', ($resource) ->
TypeResource = $resource("/api/types/:ferrari_or_porshe/:id", {},
index:
method: "GET"
isArray: true
)
return TypeResource
]
Finally, some test code:
describe 'MyApp.Controller.MyCarsController', ->
beforeEach module('MyModule')
beforeEach inject ($rootScope, $http, $controller, Type) ->
#scope = $rootScope.$new()
#typeService = Type
#scope.context = undefined
$controller 'MyApp.Controller.MyCarsController', $scope: #scope
describe '#home-page', ->
it 'contains a list of types', ->
expect(#scope.types.length).toBeGreaterThan 0
it "sets instance variables correctly", ->
expect(#scope.ferrari_or_porshe).toBe ""
expect(#scope.id).toBe ""
Which fails with:
No more request expected in helpers/angular-mocks.js on line 889
TypeError: 'undefined' is not an object (evaluating 'this.scope.types.length') in controllers/my_cars_controller_spec.js
By judicious application of console.logs, I have discovered that the issue is that the final callback on response is never reached. TypeResource comes back as [Function].
My questions is:
How do I drive the Jasmine Tests to correctly enter the Service and fetch a response? And is there any way to create direct Unit Tests for Services?
Any and all help is appreciated
The Solution is as follows: for the Service, use $httpBackend which is bundled as part of ngMock:
http://code.google.com/p/google-drive-sdk-samples/source/browse/ruby/app/lib/angular-1.0.0/angular-mocks-1.0.0.js?r=c43c943e32be395b7abca8150deb301d3cbc0dbe
Use this to mock the Rest responses. Since in my case I only cared about verifying that a GET request goes out:
describe 'Type', ->
describe '#index', ->
beforeEach module('MyModule')
beforeEach inject(($httpBackend) ->
$httpBackend.whenGET('/api/types/ferrari/1').respond([])
)
it 'for a ferrari scope', inject((Type) ->
ferrari_or_porsche = 'ferrari'
id = '1'
expect( Type.index('ferrari_or_porsche': ferrari_or_porsche, 'id': id) ).toEqual([ ])
)
And then for the controller, mock the service using jasmine spies and use jasmine.any(Function) to warn of the callback.
describe 'MyApp.Controller.MyCarsController', ->
beforeEach module('myModule')
beforeEach inject ($rootScope, $http, $controller, Type) ->
#scope = $rootScope.$new()
#typeService = Type
#scope.context = undefined
spyOn(#typeService, 'index')
describe '#home-page', ->
beforeEach inject ($controller) ->
$controller 'MyApp.Controller.MyCarsController', $scope: #scope
it 'contains a list of types', ->
expect(#typeService.index).toHaveBeenCalledWith({ ferrari_or_porsche : '', id : '' }, jasmine.any(Function))
it "sets instance variables correctly", ->
expect(#scope.ferrari_or_porsche).toBe ""
expect(#scope.id).toBe ""
Note: I make no claims as to the "canonicalness" of this solution. But it works.
Note: The API endpoints are of course tested extensively elsewhere.