I have been using Jasmine to write BDD tests for a web app. I am interested in running these same tests from the command line using Rhino, and I found this blog entry which has been very helpful. However; my app uses pusher, which offers a simple API for passing events between clients using web sockets.
My tests run fine from a browser, but running them via Rhino fails to connect to pusher. Pusher offers a debug stream, and it would show authentication errors or other failures, but it doesn't register any activity when I run my tests from the command line.
This may be a simple yes or no answer, but I haven't been able to locate any relevant documentation, and I'm brand new to Rhino so I apologize if this is a total n00b question.
My question
As the title says, does anyone know if Rhino supports the websockets API? Am I doing something else wrong here, or will scripts that rely on websockets simply not work via Rhino?
My overall goal was to use my already written jasmine tests as stress tests by running them on several EC2 instances at once; is there a good (simple?) way to do this while reusing my existing javascript tests, or should I suck it up and just write my stress tests in a server side scripting language? I am aware of selenium grid, but was hoping to avoid having to spawn new browsers to run these tests, if possible.
Thanks so much!
Ringo, a Rhino-based CommonJS runtime supports them: http://ringojs.org/api/v0.6/ringo/webapp/websocket/
Related
I have a little question here. Is there any way to build a server side JS without any use of external software. The reason for this is I am not able to install any software on the webspace but I wanted to experiment with realtime communication with the server and another user for a game or something like this.
If someone knows a way to establish something like this I would be quite happy to hear about it.
EDIT: Guys NOT NodeJS I AM NOT ALLOWED TO INSTALL ANY OTHER SOFTWARE!
https://cloud.google.com/nodejs/
or
https://devcenter.heroku.com/articles/getting-started-with-nodejs#introduction
Those $15 a year webhosts typically don't allow you advanced customization. You need a better web hosting service that allows you CLI access to the server back end.
Running JavaScript on backend requires NodeJS runtime environment. Download it here https://nodejs.org/en/
Alternatively you can can configure an instance on Heroku and run your application there. But I would suggest to try the first one.
No. Javascript is a scripting language that was designed to work within the browser. There's no out of the box solution for you, as Javascript doesn't do server-side out of the box
However, Node.Js (and others) use Chrome's V8 engine to create an event-driven runtime environment which can allow writing server-side code with Javascript. That's your best option
I have a Visual Studio solution with two projects in it.
First project is a console application written in F#. The console application is actually a simple server with web API implementation.
Second project is a web application written in JavaScript. This project contains corresponding implementation of API, which allows users to make API requests to the server.
I need to test this client-side implementation of API to be sure that it passes the right data to the server and receives the right data back. What is the best practice to achieve this?
The problem is that I need to build and run the first project before I can run tests in a second project. What is also would be good is to make these tests running on Continuous Integration. If it is matter, I use visualstudio.com for CI.
Is this possible at all without manual start of first project and then running tests?
Note that on each test run it is important to restart console application.
Yes it is possible. I would recommend you to have a look at RAML which is a way of
Documenting your API
Using the documentation to generate a client and use it for automation tests
Using Anypoint you can expose your documentation and get your stakeholders to easily test it as well.
Please have a look at Design, test and document RESTful APIs using RAML in .NET for a full run through and explanation. In this blog post I used .NET at my language of choice, but the same principle applies to other languages.
With this you can test your API before you write the client. The Anypoint platform also allows you to mock the webservice and you can use the mock for testing you client later on.
This way you can test both applications in isolation and in a programmatic/automated manner (which you can execute from your CI). RAML has also a library for generating a JavaScript client from a RAML file: https://github.com/mulesoft/raml-client-generator
Whats the difference here? I want to create a small API for queueing jobs, but I am not sure which should I be using. I'm leaning towards just using Node, but I do understand what is the point of having a web server module for PhantomJS.
From the PhantomJS docs, the Phantom webserver is still experimental and intended to manage other phantom scripts and provide an interface to those scripts from the web. It currently only supports up to 10 concurrent requests. I'd recommend using node if you are looking for a general purpose web server.
I hope someone out there might be able to help me out with a coding problem I am having. I am currently working with server side JavaScript code that executed within a third party Java application (mirth connect) that executes the implemented JavaScript using the Rhino JavaScript compiler. This is of of special interest since I sometimes have the need to interact with external Java packages.
I have been looking at ways of formalising our testing process on this code.
With this in mind I have been looking at JavaScript unit testing frameworks such as QUnit and Jasmine. Unfortunately as I understand it, these frameworks are primarily aimed at testing JavaScript code running in a browser environment, but I need to test as if the code were being executed on a server. But this could be achieved by running these frameworks with a headless browser browser.
What I'd really like to know is if this is at all possible? I have looked at many resources that claim to be able to implement this but have been unable to do this myself. If it is indeed possible, does anyone have any links or simple walkthroughs I could follow?
I'd be more than happy to provide examples of the JavaScript code I'd want to test, the Java class I'd want to call from the JavaScript and the unit tests once anyone can confirm I'm sure I'm not barking up the wrong tree with this as a possible solution.
Thanks in advance!
I'd recommend writing your tests in Groovy/Java and running them that way. It's not ideal, but Rhino provides a handy bridge to get at the JavaScript objects.
I've written about setting it up here: http://ryanbrooks.co.uk/posts/2014-03-27-testing-rhino-js-spock/
You could always try writing your tests in Jasmine and running them with Karma. You'd need to run Karma on Rhino, which caused us problems, but you might have more luck if you use CommonJS for Rhino.
My view is that (generally) Rhino is only used these days where JavaScript needs to be executed by Java processes, in which case you probably care about testing the Java-side output, but YMMV.
I want to do a smoke test in order to test the connection between my web app and the server itself. Does Someone know how to do it? In addition I want to do an acceptance tests to test my whole application. Which tool do you recommend?
My technology stack is: backbone and require.js and jquery mobile and jasmine for BDD test.
Regards
When doing BDD you should always mock the collaborators. The tests should run quickly and not depend on any external resources such as servers, APIs, databases etc.
The way you would want to make in f.e. Jasmine is to declare a spy that pretends to be the server. You then move on to defining what would be the response of the spy in a particular scenario or example.
This is the best aproach if you want your application to be environment undependent. Which is very needed when running Jenkins jobs - building a whole infrastructure around the job would be hard to reproduce.
Make spy/mock objects that represent the server and in your specs define how the external sources behave - this way you can focus on what behavior your application delivers under specified circumstances.
This isn't a complete answer, but one tool we've been using for our very similar stack is mockJSON. It's a jQuery plugin that does a nice job both:
intercepting calls to a URL and instead sending back mock data and
making it easy to generate random mock data based on templates.
The best part is that it's entirely client side, so you don't need to set up anything external to get decent tests. It won't test the actual network connection to your server, but it can do a very good job validating that type of data your server would be kicking back. FWIW, we use Mocha as our test framework and haven't had any trouble getting this to integrate with our BDD work.
The original mockJSON repo is still pretty good, though it hasn't been updated in a little while. My colleagues and I have been trying to keep it going with patches and features in my own fork.
I found a blog post where the author explain how to use capybara, cucumber and selenium outside a rails application and therefore can be use to test a javascript app. Here are the link: http://testerstories.com/?p=48