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
Related
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 6 years ago.
Improve this question
I'm caught in a fix. I've learned ExpressJS to develop a web app and I'm a quarter of my way done. Then comes along Meteor which was very recently released. It has gotten a lot of press, funding and it has the benefit of being able to port to Cordova. Now I'm not sure whether to stick to ExpressJS or transition to Meteor.
Key Points: Scalability, Ease of use, Development efficiency
Express = MVC Framework built in Javascript and is powered by Node.
Meteor = Full Stack that has the front-end and back-end components to build a real-time application.
To create the same implementation of Meteor using Express, you need to look at the MEAN stack, which includes MongoDB, Express, AngularJS, and Node. You can create the same thing in Meteor that you can with the MEAN stack, you are just going to be doing a lot more learning especially with AngularJS. Express and Angular are taken care of in Meteor using Meteor's template system and Blaze.
I would stick with Meteor. It still has a few drawbacks, but there are workarounds. It's amazing what you can throw together in little time.
You're comparing oranges with potatoes. Expressjs is backend and Meteor is fullstack, such a comparison is unfair at all!
I've been working with Meteor since 0.8 and I suffered in the skin the pain of upgrading, removing old vital third party packages, etc. you get the idea. Although Meteor reached 1.0, I don't think that the mobile component is quite ready, check github issues on it.
I think Meteor is ready for building online platforms. If you find that it doesn't play well in the mobile, you can still maintain your Meteor application and create an API on top of it, you can find packages on atmospherejs.com for it (or even use iron:router). That's what you would with Expressjs: create an API to be used by mobile devices.
About your Key Points of Meteor: Scalability - It's possible to scale Meteor although you won't a good article about it but if you take a look at Kadira, Arunoda managed to scale it. Ease of use - It's fairly easy to write a Meteor application in the beginning but in the long run you'll face some problems like I faced. Development efficiency - My experience in team wasn't that positive, we had bad architectural design choices and some bugs because new developers (even experienced ones) don't get Meteor, example: Instead of using Collections allow and deny rules, they use Meteor.methods for everything which doesn't translate to security. Some even publish the entire database to the client and say: Works great on my localhost :D
About express: I have little experience on it but the comparing it with Meteor, it's not fair at all. Meteor doesn't not the same purpose as Expressjs.
A comparison with MEAN Stack would make much more sense: http://mean.io/
Express.js is quite different from Meteor.
Meteor tries to give a good framework for everyone taking a lot of decisions (hopefully good decisions) those are usually uninteresting from the application development point of view: what transport library to use, how to synchronize data, how to build a reusable API, security, CRUD operations with the database, etc.
Instead Meteor gives you a unified experience across the stack. Since it has so much power control over backend, transport, interfaces, front-end, build tool chain - it can build a lot of neat features those would be so much harder to glue together from Mongo+Express+your favorite front-end framework+socket.io+grunt/gulp.
Read Socket.io's creator's blog on how hard it is to deliver good user experience in single-paged apps these days: http://rauchg.com/2014/7-principles-of-rich-web-applications/. Meteor does a lot of it +more. (except for the server-side rendering and predictions, at least right now).
Think about how many security holes you will have if you pick the abstractions too low level in hope to implement everything right.
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 = .....
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 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 have a server that is running Ubuntu Linux Server Edition. I once had a Windows Server and it is easy to create web services using ASP.net on Windows. Linux on the other hand does support ASP.net using Mono, but is isn't as full featured as Windows. So what would be the best way to create xml web services on a linux server box?
Thanks
A web service can be written in any language. A web service is a program that takes request and returns response (xml or json) via http protocol. You can use a web server like Apache or lighthttpd to handle the http(s) and multithreading for you and write a simple script to do the actual work. The script can be written in anything - php, perl, python, shellscript, cgi c++, free pascal cgi etc.
Of course, You can write everything on your own by using TCP sockets, but this is not your goal I guess.
For FOSS I'd do it in php, because it`s easy:http://davidwalsh.name/web-service-php-mysql-xml-json
If I want it compiled, i'd use FreePascal as in this guide: http://leonardorame.blogspot.com/2010/02/web-20-programming-with-object-pascal.html
Or If I prefer C++, I'd use QTCreator with this guide: http://libqxt.bitbucket.org/doc/tip/tech-web.html
If you want to use ASP.net then use a windows server.
If you have to use Linux for some reason then you need to learn another language to work properly in the linux environment.
Linux web development is actually a world of difference from Windows web development. In leau of the bureaucracy of "applications" and "web services" we have scripts you can invoke via Apache, and if you want to get more advanced, daemons that can handle TCP/IP connections.
If you want to use something specific like SOAP, you should mention it in there, but as far as I know, Linux web development isn't service-based like Windows is.
There are many ways to do this, but given your ASP.NET background why not give the MonoDevelop IDE a go, it has matured a lot and will continue to do so.
Another option is using Eclipse (Java or PHP).
Depends mostly on the web server and web language you run on Linux more than anything else.
If you're using Apache Tomcat, look at Axis2 (http://ws.apache.org/axis2/) and CXF (formerly XFire at http://cxf.apache.org/)
JBoss has web service support built-in (JBossWS) so it's fairly easy to use and since it's a Java EE server, it uses standard web service code that is portable.
You can also write web services using PHP if you use that on your web server.
Apache = IIS
PHP or Java EE or JSP or JSF = ASP.Net
There are a lot more choices in Linux land...
I came across the same problem recently. I wanted a thin layer to turn my SQL database into a webservice with JSON or XML support. All I wanted to do was to have to write the SQL statements... it seemed a pretty reasonable thing to ask.
However, all the options I found involved installing some sort of enterprisy "do everything" solution. So I ended up writing some "glue" which took SQL statements defined in XML "dataset" definitions, and served a simple, RESTful web service.
I documented my approach here:
http://www.nsquared.co.nz/jarvis-docs/jarvis_guide.odt
If you want to use the framework, I can give you a tarball of the latest release. It's used in three or four small applications currently, 2 ExtJS, 1 Flex, and 1 Asp.Net.
There's a plethora of materials available with a simple search for "PHP Web Service" on Google. I'm not really sure what language you're using or what type of service you want to set up so I went with PHP Soap.
http://www.onlamp.com/pub/a/php/2007/07/26/php-web-services.html
There's a lot of industry standard specification and implementation in Java dealing with all aspects of server side web programming.
Start off by an open source implementation such as Apache Tomcat and/or any of http://ws.apache.org/
I guess the best answer depends a bit on what you really need, but one option is to use any of the recent web frameworks, such as Rails, CakePHP, or Django, which allow you to easily define database backed models, and then compose dynamic sites. Turnaround on these frameworks can be measured in minutes for simple sites.
Although it is based on a commercial product the following is an excellent primer to assist you in understanding how you would develop a Java based web service on Linux. If you find a similar tutorial based on free software please share it.
"So what would be the best way to create xml web services on a linux server box?"
A web framework like Turbogears, Django, Grok, Repoze.BFG, WebPy or such.