When developing an API (in my case an API that wraps around a websockets service), is there a good way of giving it's skeletal implementation to another developer so that he can work independent of me? If my API is still in the design phase for example, I'm thinking that I could give an outline of the methods that will be available and all the possible return types.
I realise that I could just give him a dummy object with all the methods inside but it would be great if that dummy object could be tied in with his unit tests and so on.
I've been looking at [SinonJs][1]: http://sinonjs.org/ and in particular at the Stub functionality it provides. However I am not sure if what I've outlined here is an appropriate use of stubs.
Any advice appreciated!
EDIT:
I guess this question should of been:
'How to write unit tests using Jasmine, Sinon and a mock API'
It was a bit of a silly question because it turns out that Sinon actually has it's own 'fake server' which is very easy to use. In ignorance of this my first idea was to mock or spy on XHR stuff.
The code I ended up with is here: https://gist.github.com/james-gardner/11405316
See 'DummyViewSpec.js' for examples of the fake server stuff. Edits welcome!
If you are asking about an easy way to have a web app (or other REST) API up and running - http://flatironjs.org/ might be a good option for you. It's full JS stack both on the server (node.js) and client. However, you can do an API mockups with any other routing library (search npm - there are A LOT of them).
I hope it helps.
There is a tool to mockup the whole APIs using schema and random data with types
https://github.com/homerquan/kakuen
I created and used it to inject dependance of api
Related
I'm searching for a javascript mapping library I can easily integrate in my angularjs project.
I use some json objects in my javascript code that are slightly different from the json structure given by my back-end.
I have found this interesting library (https://github.com/wankdanker/node-object-mapper) that lets you specify a mapping through another object, but unfortunately it seems to work only in a nodejs environment and not in the browser.
Does anyone know a similar library working in a browser too?
Last year, I have created a port of the C# AutoMapper implementation to TypeScript / JavaScript exactly for this scenario. I have put the code at GitHub (https://b.ldmn.nl/AutoMapperTS). You can also use the library directly using the automapper-ts NPM or Bower package.
The library is almost fully documented. Furthermore, quite a lot of Jasmine unit tests are already available (code coverage is about 95%). They should provide you with some explanation of what you need.
I hope this library suits your needs. Should you have any questions and/or remarks, please don't hesitate contacting me!
I have a server written with Node and Express 4. I also have a customer which wants this to be documented with Swagger. How can this be done?
I've looked into the following tools:
swagger-node-express: Lets you do exactly what I want, except it does not support Express 4.x
Swagger 2.0 - Node-Express-4.x: Same as above but with a different approach. Could be used, except I don't find much documentation on setting it up (and I'm too slow to get it without docs)
Tools like swaggerize-express and Swaggers own tool for Node would work if I started from scratch, but I just want a way to easiliy add docs to my project so that Swagger can read it.
It wouldn't work in the long run to write a doc-file that Swagger can read because then I'd have to update it. I want to document everything in the code and not a Swagger- or readme-file, and let the documentation be available through a Swagger-UI automatically.
I may have overlooked something here, but I can't seem to find anything to help me.All suggestions are welcome. Thanks in advance.
I highly recommend looking into Loopback framework. It's framework for creating REST APIs on stereoids. It is using Express under the hood and is created by company StrongLoop, which also maintains Express project itself now.
It supports Swagger out of the box.
I tried Googling around for some examples, or well anything, but couldn't find any results. I think partially because the name of the package "connect-rest" is so generic.
Anyway, here is what i'm looking to do. I am using the Node module "connect-rest" to build a server side API. It is mostly finished at this point, and i'm now looking to secure it. Now the module itself has a system of authentication with API Keys, which is well and fine, but not very secure for Javascript clients, since anyone could just browse the source and grab the key. And trying to secure a key -- well it just doesn't work without getting super complicated.
So instead i'd rather use a standard OAuth setup. I was hoping to use Passport in combination with connect-rest and wondering if anyone has done this before or point me to some examples?
I found exactly what I needed with OAuthorize: https://github.com/jaredhanson/oauthorize which is written by the same guy as Passport.
We used the following guide for our own learning when we started a similar process: http://scotch.io/tutorials/javascript/easy-node-authentication-setup-and-local
Also take a look at MeanJS. It has a built in authentication/user system.
I'm developing an Webapp.
It consists of 2 parts. A node rest server and an angularjs client.
The app is structured this way: Rest Server <--> Api Module <--> Angular App
The server is currently well tested.
I have Unit Tests and Integration Tests.
The Integration Tests are accessing a real database and calling the rest api over http.
I think this is as high level as it can get for the server testing.
The integration tests run fast, too.
I'm pretty confident that the way I tested the server is sufficient for my use case and I'm happy with the results.
However I'm struggling how to test the angularjs app.
I have unit tests for the relevant directives and modules. Writing these wasn't an issue.
I would like to write integration tests that cover user scenarios.
Something like a signup scenario: The user visits the website, goes to the signup form, and submits the form with the data.
The angularjs team is moving from ng-scenarios to protractor.
Protractor is using Selenium to run the tests.
Therefore there are two scopes: The app scope and the test scope.
Now I can think of three different abstractions I could use.
And I'm not sure which one suites me best.
Mock the Api Module
Mock the Rest Server
Use the full server
Mock the Api Module
In this case I would need not to setup a server. All Interactions are running in the browser
Advantage:
No server is needed
Disadvantage:
The api is in the browser scope and I have to tamper with this.
I really like this solution, but I find it difficult to mock the Api.
The Api needs to be modified in the browsers scope.
Therefore I need to send the modification from the test to the browser.
This can be done, however I don't see how I could run assertions like mockedApi.method.wasCalledOnce() in the tests scope
Mock the Rest Server
Advantage:
Client would be unchanged
Only one scope to deal with
Disadvantage:
One has to setup the Rest Routes
I could create a complete Mock Rest Server in nodejs.
Protractor Tests are written in nodejs, thus the control of the server can be done in the test.
Before I run the test I can tell the server how to respond.
Something like this: server.onRequest({method: 'GET', url: '/'}).respondWith('hello world')
Then I could do assertions like wasCalledOnce
Use the full Server with Database
Each test is running with a complete server and can add elements to the database.
After each test one can look at the expected elements in the database
Advantage:
Can be pretty sure, that if these tests are running the app is functional in the tested use case
Disadvantage:
I already made a fairly intense integration test with the rest server. This feels like doing the same again.
Setup depends on the full server
Current Conclusion
Mocking the Api would separate the server and the client completely.
Using a Mock Api would be a higher level test, but would require a fake server
Doing a full integration test would give the best reliability, but this is also highly dependant on the server code
What should I pick? What would you do?
I think I answered this same question in the Protractor google group. I am much of the same mind as you about wanting no server but wanting all of my test code in one place (in Protractor) and not split between Protractor and the browser. To enable this, I took matters into my own hand and developed a proxy for the $httpBackend service which runs within Protractor. It allows one to configure the $httpBackend service as if it were running in Protractor. I have been working on it for a while now and its reasonably full featured at this point. It would be great if you could take a look and let me know if I am missing anything important.
https://github.com/kbaltrinic/http-backend-proxy
It is an excellent question, which has nothing to do with a particular tool. I had to face the same problem on a big "greenfield" (ie started from scratch) project.
There is a problem of vocabulary here : the word "mock" is used everywhere, and what you called "integration test" are more "full end-to-end automated functional testing". No offence here, it's just that a clear wording will help to solve the problem.
You actually suggested the correct answer yourself : #2 stub the rest server. #1 is feseable but will be soon too hard to develop and maintain, #3 is an excellent idea but has nothing to do with UI testing and UI validation.
To achieve a high reliability of your front-end, independently of your backend, just stub the rest server, i.e. develop a stupid simple REST server that will idempotent, i. e. will ALWAYS answer the same thing to one http request. Keeping the idempotence principle will make development and test, very, very easier than any other option.
Then for one test, you only check what is displayed on the screen (test the top) and what is send to the server (test the bottom), so that the full UI stack is tested only once.
The full answer to the question should deserve an entire blog article, but I hope you can feel what to do from what I suggest.
Best regards
Here is an approach for writing integration tests for your Angular code. The key concept is to structure your code in a way that lets you invoke the various functions in a way very similar to how it's consumed by the UI. Properly decoupling your code is important to be successful at this though:
More here: http://www.syntaxsuccess.com/viewarticle/angular-integration-tests
This is a great question. This is how I would do it:
As you already have the angular unit tests for the relevant directives and modules this is perfect.
The other thing that is perfect is that your server Integration Tests are accessing a real database and are also making sure the rest api over http works.
So why not just add some high level integration tests that include angular and your server at the same time.
If you can avoid mocking, why not save the work to maintain the extra code, if possible.
Also a good read: http://blog.ericbmerritt.com/2014/03/25/mocking-is-evil.html
Mocking the REST server is the best, cleaner option in my opinion. Try Mountebank (http://www.mbtest.org). An amazing Virtualization Service tool.
I'm piecing together a jsTestDriver/Jasmine environment for testing our front end code and I'm seeing a lot of references to Sinon.js for stand-alone (or drop in) spies. Could someone describe what Sinon.js brings to the table that Jasmine doesn't for testing the UI?
* Posting it as an answer, since this didn't fit in the Comments section! *
FWIW, We used SinonJS to create a FakeHTTP(LinearEPG)server component for implementing the REST-APIs of the real-server that hosts the EPG(Linear TV Program Schedule) info.
Then, we used this FakeHTTP-LinearEPG server in two modalities:
Used with the Web-App displaying EPG for testing the navigation etc.
Test the Javascript-code that fetches the EPG along with Jasmine UT Specs.
Granted, we could have implemented the FakeServer functionality using Jasmine-Spies, but it seemed to be bit convoluted. On the other hand, the FakeServer provided an elegant and quick way to emulate the Server providing the REST-interfaces.
SinonJS-based FakeServer proved to be quite useful when the server itself was still under development at that time!