Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Our team is planning to develop a framework to automate manual test cases. But we are stuck in choosing between javascript and java. With a bit of search, we found that Webdriverjs is the selenium bindings for javascript. Now, the main hurdle is whether we should go for javascript with webdriverjs or java with selenium-webdrier?
We already know java with selenium-webdriver but and as we are moving ahead for a new framework we just want to open easy, fast and more reliable option.
Please suggest javascript with webdriverjs(we need to learn javascript for this) or java with selenium-webdriver?
We ran into the same challenge that you are seeing now.
There are a lot of selenium engineers on the Java stack but not much on the Node.js and selenium-webdriver stack.
Most newer modern testing frameworks are done in Node.js since both the front-end and back-end are done using NodeJS and will continue this trend. The question that I would ask is whether the development team is using Java (e.g. Tomcat) or are they using Node.js to develop their product. If they are using Node.js then it would be ideal to have the test framework written in the same language as well.
This is to facilitate
Collaboration between development and automation team, locators and etc..
Lessen the friction for developers to write selenium tests
There is a very good presentation on this by Marcel Erz at one of our South Bay Selenium meetups. I highly recommend you to go through it before making a decision.
Java vs. JavaScript (for UI testing)
Most tests written by Front-end Engineers
Unfamiliarity with Java and its eco-system
Context switching
Less likely to embrace testing
http://www.marcelerz.com/blog/talk-nodejs-based-selenium-testing-south-bay-selenium-meetup
Now if you are set on using Javascript the main challenge is of-course async-ness. Most automation engineers are used to sync patterns in Python and Java. It will take some time to get used to the async behavior of javascript. But the end result is worth it.
Our framework is mainly written in Node.js and we use Mocha as our harness and test runner. The recommended assertion library is Chai but you can use others if you need specific needs.
Our selenium library of choice is WebDriverJs (case sensitive) aka selenium-webdriver on npm which is the official JavaScript port. One of the main reasons that we went with selenium-webdriver is code readability and the ability to achieve sync-like syntax out of the box to keep Java test engineers in mind. This is achievable by leveraging the built-in Promise Manager control flows and Mocha Test Wrapper that automatically handles all the calls into the promise manager which makes the code very sync like.
https://code.google.com/p/selenium/wiki/WebDriverJs#Writing_Tests
Then it's a question of adding in your own framework and building the page objects. Page Objects in Javascript is a whole new beast you will have to get a good grasp of Prototypes and how you can emulate Java's inheritance.
You should also use selenium-standalone in npm as your only communication point to selenium for both local and remote execution instead of creating Driver instances (local/remote) in the test. This is so that the framework has the same interface and make things consistent. You don't want to keep track of multiple local driver executables and updating them. One package takes care of everything.
If you have read until here and you are pretty much certain that you will go with the Node.js route instead of Java. Below is a very simplified version of our framework that can help you get started. It has all of the implementations that was described above. Also any pull request is welcomed!
https://github.com/mekdev/mocha-selenium-pageobject
I'd personally choose selenium-webdriver package and instantiate the different drivers as needed. You're then not locked into just js driver.
Our team utilizes the selenium remote / grid for parallelization but in many instances we need a js driver.
Example in its:
WebDriver wd = new WebDriver()
RemoteWebDriver rwd = new RemoteWebDriver()
ChromeDriver cd = new ChromeDriver() // for chrome browser
JavaScriptDriver jsd = .....
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
My client has a new system in development using node.js.
I need to write automation scripts for the system and my client has recommended me to go with node.js this time so the developers can also take part in creation of Automation scripts.
I need recommendation for Test Automation frameworks that I could use. I have experience working with Selenium WebDriver using Java.
Any guidance and direction would be very helpful.
Thanks.
A reasonably logic option in your case would be to try webdriver.io, as it is an implementation of the Selenium 2.0 bindings for NodeJS.
You might try out NightwachJs. I did some experimenting with it recently and it seemed a reasonable node.js compatible automation framework.
There are abundant of node.js packages you can use for test automation, which covers almost all types of test automation, for example,
For API testing, you can use "got", "request", "axios" etc.
For Web UI testing, you can use "selenium-webdriver",
webdriver.io, puppeteer, etc.
For mobile or Windows UI testing, you can use appium
All these packages can be found on npm registry:
www.npmjs.org
If you want to use natural language to define your test case and associate them with the automation code, you can use the BDD tool cucumber.js
BTW, one free tool that can be used to author all above types of test automation is CukeTest, which is free to download and use.
https://www.protractortest.org is also popular if you have an angular application
We currently use Puppeteer in the system to test our UI functions. We use a tool called Last-hit.https://github.com/last-hit-aab/last-hit
This tool only needs recording and playback. It is very simple.
Implement nightwatch.js
advantages
lightweight library
easy to implement in Node.js
can be integration to CI /CD tools
also available docker images
You can use WebdriverIO, NightwatchJS or Cypress to automate non Angular applications. Use Protractor for Angular applications.
There are few testing framework such as Jasmine, Mocha and CucumberJS
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
So we've been using node for quite a while now and I must say, with the growing community for node, people are developing lots of awesome modules and frameworks too. But as we are working on more and more projects, I get confused sometimes as to which framework to go for. So far we've used following frameworks:
Express - One of my favorite frameworks for node and this was the first too when we started making apps in node.js.(I think this also was the first to gain so much popularity). We do have issues like callback hells but provided that the routing and the code organization is much more cleaner, we were pleased to use it.
KoaJS - Another one from the TJ and team, and this is just awesome! Using ECS 6 when any of the browsers hardly support them. (Specially when it helps you remove the callback hells completely). We had some issues with https compliance with Koa and had to re-write the entire server using hapi and also the fact that it depends on the unstable version on node for now.
Hapi - This is our most recent adoption and haven't done much with it, but the most fun part of this is the joi module that helps us validate requests(easily) even before they hit the actual server and also the automated docs generation.
Synth - I haven't interacted much with it, but while reading the docs, I came across
Use services and dependency injection just like AngularJS but on the
back-end!
which is awesome, but since it's in beta still, I'm not thinking of using it anytime soon.
So when trying to go for a framework for your app, Is there any specific set of features that one framework is good at and the others don't? Because honestly, we adopted most of the frameworks just with the intent of trying them out and apart from syntax differences (except Koa that uses ECS 6) and how they handle routes, I couldn't find much differences among them.
So my question is should we adopt any framework just by looking at it's popularity(which is what people generally do) or there is some checkpoints we need to consider while doing the same?
Any suggestions/help appreciated.
Edit
I wanted to add on that my intention for this question is to find out the key points to consider while opting for any of the node.js framework (rather than just depending on it's popularity or how many big names are using it). For the front-end we can easily tell because we already know or have been told the key features that would help development easier(the diff between angular & backbone can be an example) But for the node.js frameworks that isn't any way.
I would request others to consider my edits too.
I'll try and keep this answer as non-opinionated as possible. Please edit and help me improve this. This is a important topic and should get a good answer.
Express.js
Pros
Express.js is the big guy, fairly old and incredibly popular.
Easy to use views
Very Lightweight
Cons
No fancy features
Koa.js
Pros
Lightweight
Koa is the maybe successor to Express
No callback hell, thanks to ES6 generators
Built by the same guy as Express
Cons
Fairly new, not super refined
Uses ECMAScript 6 features, meaning you need Node.js v0.11 (unstable)
Hapi
Pros
Many official modules, but not a ton of third-party ones
Developed by a large corporation that uses it for their own products
Cons
Built by Walmart
Different syntax for specifying routes than Koa or Express.
Itself and all the official modules have weird names
Synth
The first back-end framework specially designed for single-page web applications.
Pros
Designed for being the backend single-page websites, ala Angular.js
API First
Dependency Injection, familiar to those coming from Java
Designed to do a ton of the backend things, allowing you to work on the frontend
Cons
Dependency Injection, disliked by quite a lot of people because Java is the only reason it exists
Very new, currently in beta
Doesn't work well with more traditional websites
More Resources
TechEmpower Framework Benchmarks (limit to Node.js) Benchmarks of lots of web frameworks, currently only has raw Node.js, Express, and Hapi for Node.js.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am doing a POC in which I have to manipulate DOM before giving HTML content to client/browser.
Some Use Cases:
Inject a javascript in html page and this javascript is customer
specific.
Inject the stylesheet according to the theme chosen by user earlier.
... More such cases are there with some business logic.
I have finished all use-cases. I have implemented it in Java using Jsoup. I have also done it in Node Js. I have to decide which technology to choose ?
Does anyone know any pros/cons in both techniques ?
Please suggest how should I test which of the two is better. Any tools available to test out the memory used/resource usage/time taken etc.
Though I have already computed time in both cases.
PS: Please feel free to suggest any other technology for server side DOM manipulation and tools to test out its performance and memory.
Choosing between Java/Node.js depends on the application you are building and people will always come up with benchmarks to show performance on one is better than the other. Most of these suggestions will not suit your use case, so instead consider your application, TCO, time to develop etc as parameters apart from raw performance and take a call.
Remember that node.js is a single threaded async i/o model vs the multithread sync i/o model of java, and that node can be ridiculously fast out of the box whereas java comes with lot of features that can come in handy later. Again, these are subjective too.
I would suggest DOM manipulation is something you should avoid serverside and try to offload it to client side javascript or use better templating engines. If it is unavoidable, Node.js has good options - try to use the module cheerio which is faster than heavy weight jsdom.
Again, using these libraries has its tradeoffs. Cheerio does not have advanced DOM manipulations - it tries to achieve jquery like API on the server while jsdom is a full fledged DOM engine.
It depends on your needs and setup. The question is what's the purpose:
small app - use NodeJS, it will probably consume less memory than Java
larger (modular app) - Java
You have to test them yourself. Regard the performance, resource usage and the speed of development.
We cannot choose for you.
Closed. This question needs to be more focused. It is not currently accepting answers.
Closed 9 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
So I've been hearing/reading alot about meteor.js. The tutorials make it seem very sporty as a framework, but I'm still a bit of a novice when it comes to web programming.
I've been trying over the last month and half to really learn node.js and figure out how it all comes together. I like the how fast and easy it is to get up and running, and the community that comes along with it (which is exemplified by the mind blowing number of frameworks you can get for Node).
But what about meteor? What are the real advantages of it, and what's the difference? Has anyone started as a node.js user and 'converted' or is it still more of a curious new framework?
A loose analogy is, "Meteor is to Node as Rails is to Ruby." It's a large, opinionated framework that uses Node on the server. Node itself is just a low-level framework providing functions for sending and receiving HTTP requests and performing other I/O.
Meteor is radically ambitious: By default, every page it serves is actually a Handlebars template that's kept in sync with the server. Try the Leaderboard example: You create a template that simply says "List the names and scores," and every time any client changes a name or score, the page updates with the new data—not just for that client, but for everyone viewing the page.
Another difference: While Node itself is stable and widely used in production, Meteor is in a "preview" state. There are serious bugs, and certain things that don't fit with Meteor's data-centric conceptual model (such as animations) are very hard to do.
If you love playing with new technologies, give Meteor a spin. If you want a more traditional, stable web framework built on Node, take a look at Express.
Meteor is a framework built ontop of node.js. It uses node.js to deploy but has several differences.
The key being it uses its own packaging system instead of node's module based system. It makes it easy to make web applications using Node. Node can be used for a variety of things and on its own is terrible at serving up dynamic web content. Meteor's libraries make all of this easy.
Meteor's strength is in it's real-time updates feature which works well for some of the social applications you see nowadays where you see everyone's updates for what you're working on. These updates center around replicating subsets of a MongoDB collection underneath the covers as local mini-mongo (their client side MongoDB subset) database updates on your web browser (which causes multiple render events to be fired on your templates).
The latter part about multiple render updates is also the weakness. If you want your UI to control when the UI refreshes (e.g., classic jQuery AJAX pages where you load up the HTML and you control all the AJAX calls and UI updates), you'll be fighting this mechanism.
Meteor uses a nice stack of Node.js plugins (Handlebars.js, Spark.js, Bootstrap css, etc. but using it's own packaging mechanism instead of npm) underneath along w/ MongoDB for the storage layer that you don't have to think about. But sometimes you end up fighting it as well...e.g., if you want to customize the Bootstrap theme, it messes up the loading sequence of Bootstrap's responsive.css file so it no longer is responsive (but this will probably fix itself when Bootstrap 3.0 is released soon).
So like all "full stack frameworks", things work great as long as your app fits what's intended. Once you go beyond that scope and push the edge boundaries, you might end up fighting the framework...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I see a lot of potential of doing Node.JS-like development on the JVM, with its heavily optimized runtime.
At this moment in time, I see three projects that aim to bring a node.js-like style of development to the JVM:
Apache Deft
Webbit
Vert.x (formerly Node.x)
Should these projects team up?
What are their relative strengths and weaknesses?
Which project has the most momentum?
Disclosure - I'm the vert.x guy :)
Vert.x is a fully fledged platform for building polyglot, scalable, asynchronous web-enabled applications.
It is heavily inspired from node.js but goes further than node.js and provides a distributed event bus which reaches from the server right into client side JavaScript thus creating a super simple model for so-called "real-time' web applications. We also ship with a mailer and a mongodb persistor. There's a full tutorial here http://vertx.io/tutorials.html
But the probably the main thing that sets it apart from other async frameworks is it's polyglot nature. The same (or similar) API is available in Java, Ruby, JavaScript and Groovy (with Clojure, Python and Scala support to follow).
Vert.x really takes advantage of true multi-threading on the JVM to provide scalability and performance than node.js cannot touch.
If you don't want the whole platform. Vert.x can also be used as a library for providing HTTP, TCP, websockets, sockjs, eventbus, etc support in your Java or Groovy application.
For more info pls see the website http://vertx.io
Disclaimer: I'm the Webbit guy
There is definitely a lot of overlap between the 3 projects. When I built Webbit I was not aware of the other two - had I been, it may well not exist, or I may have spent my time contributing to the others.
I can talk a bit about Webbit...
It is not a multi-purpose evented IO framework. Or network protocol toolkit. Or filesystem abstraction. Webbit only does a small fraction of what the others do.
Webbit is also not a full-featured web-framework. Like Node.JS or the Servlet API, it provides the core building blocks for building higher level frameworks, but leaves this to external projects (like Webbit-EasyRemote or Webbit-REST).
What Webbit focuses on is being a simple, embeddable, non-blocking, HTTP and WebSocket server.
Because it takes the 'do one thing and do it well' approach, it has also been designed to be used in conjunction with other libraries. It allows external java.util.concurrent.Executors to be passed in and avoids singleton thread contexts, making it particularly well suited for integrating with Actor style concurrency libraries such as Jetlang and HeySync.
Vert.x and Deft bring complete frameworks for out-of-the-box Node style development. Webbit is just a small tool that can help HTTP/WebSocket enabled your application. There is a need for both of these and it really depends on your needs (and personal style) as to which is more appropriate.
Disclaimer: I'm an Apache Deft committer.
Apache Deft has more in common with tornado and twisted than to node.js, whereas vert.x is heavily influenced by node.js. Tim Fox from wmware is doing a great job with vert.x and the development speed is really impressive.
vert.x has a couple of examples available.
Some Apache Deft examples.
Apache Deft also has a bigger "demo application" that should give you an idea of how you could use the framework for other things than http.
AFAIK webbit is currently aiming to be a "WebSocket and HTTP server".
If they should team up? Absolutely :)