I use simple uptime monitors like statuscake, uptimerobot, etc. to verify that my sites are up. The problem is that some of the sites are ASP.NET applications with complex __doPostback interactions -- basically, the user fills out a form, clicks submit, and then ASP.NET-generated javascript takes them to the next page.
My idea was to write a CasperJS (basically an easier API for PhantomJS) script to simulate this user interaction and test to make sure it works.
I have the test running in CasperJS and now I'd like to expose the test as its own REST API so I can have my uptime monitor hit it every few minutes. The REST API would return 200 if the test is successful; some error code if not.
I would normally throw restify or express around the logic, but you need to run CasperJS via casperjs file.js instead of via node, which means I can't run restify within it. I've looked at PhantomJS, Nightmare, and Zombie. If you know for sure those would work for this let me know; otherwise I had issues with their API that lead me back to CasperJS.
This feels a bit like exposing a test suite as an API if that gives any ideas.
Any suggestions?
PhantomJS has a built-in server, you may use with CasperJS like shown in this answer: CasperJS passing data back to PHP
Related
I want to test the Web API of a system which has also a CLI accessible via a telnet connection. The tests must verify that the response given to the API requests matches the output of commands given to the CLI.
The problem is that as far as I know there's no way to initiate a telnet connection from inside a postman script.
What will be the best way to achieve this?
Maybe postman is not the best tool for this job?
What will be the best way to achieve this?
A dedicated script written in NodeJS or any other programming language with or without help of some test framework like Jest \ karma. For sure not Postman.
You can use Postman to run the above mentioned script with pre-request script but it just make the all process much more complicated. Almost any modern script language will give you the option to send http request, no need to use postman.
Maybe postman is not the best tool for this job?
You are right, it's not.
I am working on an RESTful API in Node.js as a contractor, which is currently being used by a couple of blackberry apps written by other contractors. The stack is very common: Node, Express and Mongoose, running on heroku.
Consider the following API call:
curl "https://my-app.herokuapp.com/v2/rest/documents/?view=tree&annotate=ratings,accessible"
When a Blackberry app written in Java makes this call, it works fine every time.
Now consider this one:
curl "https://my-app.herokuapp.com/v2/rest/documents/?view=tree&annotate=ratings%2Caccessible%2CcontentSize"
When an Adobe Air Blackberry app makes this call, it often gets an HTTP 503 from Heroku with the Heroku Error code H12, which means that the request timed out. Although, on the BB app it does display "501 Error" when this happens. The logs show no 501s, only a 503.
However, if I make the same call to the server using curl, the response is successful, and for a while afterwards it is successful on the same BB app which previously had trouble with it, too. Almost as if the response succeeded, was cached on Heroku's side and then stayed cached for a while (this is speculation).
The main difference is the inclusion of contentSize in the annotate query-string parameter. But clearly, it isn't slowing it down too much since it seems to work fine when called through curl.
Sadly, I do not have access to the source code of either of the BB apps, and the developers are generally quite slow to respond since it is not their only project.
So I was hoping that somebody on SO might have some experience with this kind of a problem and maybe point me in the right direction.
Thanks!
Is the app in question scaled enough to prevent idling? I ask in particular as the "curl-ing then allows BB to work for a while". Perhaps the timeouts are occurring when BB app is trying to access the idled service? Not sure off the top of my head outside of that, but might be a good place to start looking at least.
I am developping a RESTful Node.js API (express+mongoose)
This API calls a third party Oauth API (google, facebook, whatever).
I've been quite happy setting up automated testing with mocha+chai+request so far, but I'm having trouble mocking the third party API to test the route (of my API) that calls it.
I've tried using nock, but it doesn't work for my use case.
To run my tests, I start my API (npm start), and in another tab, I start the test suite (npm test). The test suite uses request to test the API over HTTP.
Hence I think nock doesn't work here because it is mocking http in the 'test suite' process and not in the 'API' process.
I absolutely need to mock this third party call for 2 reasons:
1. I want to be able to run my test suite offline with everything running on my laptop
2. Since the third party API uses Oauth, hard coding credentials in the test suite (even for a test account) doesn't seem too easy.
I would really love not to leave this giant hole in my test coverage, so any advice would be much apreciated!
so this is how I solve my own problem. I came up with it on my own while setting up proper testing for an app for the first time so feel free to suggest improvements. Disclaimer: I use coffee script
The first step was to launch my app from another file, starter.coffee, that essentially looks like this:
# This file starts the API locally
require './test/mocks/google_mock'
require './app'
So to start my server for tests, instead of doing coffee app.coffee, I would do coffee starter.coffee.
The google_mock.coffee file mocks the Google API before the app is launched from the app.coffee file.
For that I use the nock! package.
The google_mock.coffee files looks like this:
nock = require 'nock'
# mocking up google api
googleapis = nock('https://www.googleapis.com')
.get('/userinfo/v2/me')
.reply(401)
with a lot more lines for mocking other Google api calls.
In my application i need to use tropo application with node.js to send,receive message and call and answer phone calls.I saw the documentation but i didn't get any idea.Can anyone help me.
Disclaimer - I have never worked with tropo, but this is how I understand it works:
You write a script that tropo can parse, in most languages, to perform some function.
You link up that script to a number using tropo's web interface.
You / a client phones that number, tropo fetches your script and executes it.
Here is a full walkthrough of how everything above works: https://www.tropo.com/docs/scripting/creating_first_application.htm
NOW, if you want your script to do dynamic things, you need to host it yourself. For this you can use node.js:
You write a script that changes based on time / user data in node.js
You link up the script using tropo's web interface.
When someone calls / texts the number, tropo now fetches the dynamic script from your node.js server.
This node.js api can be used to write scripts on your node server: https://github.com/tropo/tropo-webapi-node, https://www.tropo.com/docs/webapi/new_tropo_web_api_overview.htm
Finally, you might want to dynamically create different scripts for different users and hook them up to individual numbers. At this point you use the REST API to automate the "number hooking up work" you used to have to do manually on tropo's website. You can use any node REST client, like request to do this. Here are the API docs: https://www.tropo.com/docs/rest/rest_api.htm
I am building an app with locomotive.js, and I am looking to build my test suite using the Mocha test framework. I am also new to TDD/BDD in general, so please take that into consideration. I am curious if anyone can point me in a good direction to start testing a locomotive based app.
My biggest question would be:
How do I test a controller's actions?
Can I test an initializer?
Are there best practices around creating test request objects?
Testing controller actions
It depends on what exactly you want to test. Controller actions usually either return content, or pass (perhaps in case of errors) the request along the server stack, so testing them means using something like supertest to check for the correct responses (the supertest page also mentions how to use it together with Mocha)
Can I test an initializer?
Testing an initializer by itself is difficult, because they require to be run within the context of a LocomotiveJS application. However, you could create a test just booting up the application, which during the booting process will also run all initializers. I just added a simple Mocha-based testing framework to my Locomotive + Sequelize boilerplate project which shows how to boot the Locomotive app from within Mocha.
Are there best practices around creating test request objects?
If you mean how you can check responses to requests, look at the aforementioned supertest or perhaps mocha-headless.