I have spent hours trying to set up an automated testing environment for my AngularJS applications that I can run from Maven (capturing results in Bamboo)
A Google search reveals frameworks galore, based on Jasmine, Karma and generic JavaScript frameworks.
But for some reason the installation of these never goes as described.
Can anyone just point me to a set of downloads that I can install manually to proper directories, that will just execute my unit tests?
I asked a similar question previously and got down checked and requests to close. If you need to check me down, please leave a reason, as I am besides myself with frustration trying to solve this, and I am sure there many other developers experiencing the same issue
Testing javascript is not a totally mature thing, so there isn't a great diversity of good tools for doing so. Jasmine and Karma are the current best ways of doing that.
Those tools are best managed using bower, which is a nodejs package. So you'll have to install, in this order:
nodejs
npm (node package manager)
bower (using npm)
jasmine and karma using bower
phantomjs, and whatever other dependencies your javascript needs (presumably angular)
Then you can run the tests.
I found this package for maven with some brief googling, but god knows how to set it up:
http://searls.github.io/jasmine-maven-plugin/
There are many tutorials on going through this process. You have to accept that these are currently the best tools for doing this and give it your best shot. If you post more specific issues regarding the 'installation that never goes as described' of jasmine and karma you will get assistance.
you can use for example yeoman or angular-seed. both will require nodejs and optionally ruby. both will set you with phantomjs, jasmine, karma, bower and many more. however i would avoid combining that build with maven. imho it's far from perfect. java tools will never be as good as native js tools for building js project. if you really want to combine the builds then use java only to call nodejs and nothing more
Related
Hello I am a frontEnd developer.
First, I don't know much about the runtime environment.
Is it possible to convert my project into Deno with Node?
Even if I change all of my code,
I'm not sure if the libraries I've received can run in a Deno environment.
(too many libs...) (React, Apollo, many many many)
And since the current webpack settings are very complex and difficult to understand, (And I understand very little about the build system.)
I am not sure if this can work in a Deno environment.
In my opinion, it seems impossible, I will only use Deno when working on a new project, Or wait for someone to create a migration guide.
What do you think about this?
Add
Obviously, it would be impossible if the libraries I used were not registered in the Deno repository.
And second, there seems to be a node compatibility issue.
Now i am sure that i can't covert it to deno.
Thanks
There is Denoify.
This tool takes as input a TypeScript codebase that was meant to target node and/or the web and spits out a modified version of the source files that are ready to be deployed as a Deno module.
It also helps to deploy on both NPM and deno.land/x
However, it is still under active development, not all node builtins are supported yet and you will probably have to make some changes here and there on your codebase to comply with the requirement Denoify sets.
Also, I am the author.
You're using many npm packages in your node project.Deno doesn't work with them.So either you'll wait to deno to be mature enough or you're gonna keep building your projects with node until that time.So i think if you want to take full advantage of deno, you should wait for deno to mature
Any code you write in pure JavaScript or TypeScript will work both in Node.js and Deno.
However, it's more than likely you have used Node.js-specific features in your current project. requires, calls to native Node.js APIs like http, util, and many others will not work in the Deno runtime.
Also, these kinds of Node.js-specific APIs are used in most Node.js libraries, so you'll have to do a complete rewrite to Deno.
I am not sure enough but as you have a Node.js project you should be using npm packages so until and unless those npm packages you use have alternative Deno packages it isn't possible if not then as #IsaToltar said to wait for it to be mature enough.
but if you can tell us what third-party npm packages you use then we might be able to find an alternative Deno package for that.
I hope it helps.
Deno now supports node-based projecs + NPM, it is considered to be stable, although still a work in progress.
To learn more, take a look at:
https://deno.land/manual#v1.29.2/node https://deno.land/manual#v1.29.2/node/how_to_with_npm https://deno.land/manual#v1.29.2/node/std_node
We are currently building our frontend js codebase (angularjs) using nodejs with grunt, which seems to be a popular setup, but we are not happy with this solution. Does anyone have suggestions for a build setup for e.g. linting, minimizing our js, running less, etc (in addition to some custom steps for angular in general and for our application specifically) without using nodejs at all?
I would leave it at that to avoid starting a flamewar, but here are, for context, some of the shortcomings of the current setup in our view:
grunt does not have even the basic functionality of a 1970s build system, like automatically re-building only files that have been modified based on file modification time
npm is causing constant headaches running on our build servers at every build
If grunt does not have even the basic functionality of a 1970s build system, why won't you use a 1970s build system then?
Just use make if that's what you're happy with. It still works fine. There's no reason not to use it if it you're satisfied with how it works.
I'm trying to use webdriverio with the jasmine test framework. I can run my test by typing jasmine at the command line. However, when I do wdio wdio.conf.js it opens a bunch of extra browsers which don't do anything. I'm just wondering what the point of the wdio.conf.js file is when I can just run jasmine at the commandline. Ultimately it's the same thing, right? However, I can't get the wdio.conf.js file to work in the same manner so it's useless to me. Perhaps I'm not managing the browser clients correctly but I don't see any guidelines on how this is commonly done. I read the documentation but it's pretty vague beyond auto-generating the wdio.conf file so that 'everything just works'. Am I supposed to use grunt or gulp to run my tests or are those tools separate from the wdio.conf idea?
I'm Just trying to get my head around all these different tools. All I need to do is make multiple automated tests to test a website. Thanks for your help.
This may help, https://github.com/webdriverio/webdriverio/blob/master/examples/standalone/webdriverio.with.jasmine.spec.js
I asked a similar question, which was answered by the main contributor here, Running WebdriverIO 'spec' tests as node file
I'm about to start digging into Meteor for real (instead of just reading about it). I'm a near-complete noob but I've at least determined I'm going to use Sublime Text as my editor vs webstorm. I know I need a git account (going Bitbucket there). What else?
Are yeoman, grunt, and bower, (and lineman?) which seem like the workflow tools of the day, also necessary for writing a non-trivial app? It seems like Meteor already does a lot of the main functionality of these tools.
Do I need a testing suite like Jasmine (at least to get started?)
Anything else I'm missing? I just want to get everything I need (yes, including a couple good Javascript books) before I start.
You'll need the basic elements you already have (node, npm, git and ruby). You seem to know a little bit about web apps so I'll try analogies.
Yeoman essential purpose is to scaffold, meteor will do a really basic scaffolding for you. If you want to have a more advanced scaffold tool I encourage you to try em : https://github.com/EventedMind/em by Chris matter.
Grunt basic tasks equivalents are handled by the meteor commands (server, livereload, build, deploy...)
Bower is a package manager, I highly encourage you to use meteorite and its repo atmosphere (https://atmospherejs.com/) as your package manager. Actually, meteorite commands (mrt) are going to replace meteor commands in your projects. Eventually, atmosphere and meteorite are going to be fold into the core of meteor. (see meteor roadmap : https://trello.com/b/hjBDflxp/meteor-roadmap)
(note that you can use npm packages to)
All the essential functionalities of Lineman are handled by meteor.
However, some tasks are NOT handled by meteor.
I run the classic compass watch on my sass folder.
A good testing framework for meteor is Laika : http://arunoda.github.io/laika/
To start, you can go to discover meteor : https://www.discovermeteor.com/. For more advanced learning; go to evented mind : https://www.eventedmind.com/
The first thing you want to learn is how to handle iron-router
EDIT
There is now two major resources to start :
https://guide.meteor.com/
https://themeteorchef.com/
Iron router has been replaced by flow router ; there is a guide to use it :
https://kadira.io/academy/meteor-routing-guide
To manage scss :
https://atmospherejs.com/fourseven/scss
The view layer :
React replaced Blaze
So to preface my question, I'm coming from a Java back-end developer perspective, where we use Maven to build. I have worked on testing on a server-side Node project we recently developed, but now I'm moving on to setting up testing on our front-end JavaScript client. I'm not very well-versed in front-end development and this is really my first foray into that.
All that being said, I'm thinking I'm going to use the following technology stack for our front-end testing: Eclipse IDE, Maven build process, Mocha testing framework, Chai assertion framework, Nock HTTP mocking framework, Sinon mocking/spying/stubbing framework, Rewire dependency injection framework. That all should be fine, and since that's the stack we use for our Node project, I would like to keep the front-end setup as similar as possible.
So, this is where my knowledge breaks down, though. I cannot seem to understand the difference in dependency management between our Node project and our front-end JavaScript project. I cannot see why I would not continue to use NPM, integrated into our Maven build, to handle dependency management and installation.
I see many people advocating Bower, but after looking at its page and docs, I still am not seeing what niche it fills that NPM would not. I am seeing a lot of adamant rejection of NPM insofar as browser dependency management goes; the main reasoning being that NPM is designed for server-side Node projects, and not for the front-end space. But who cares? Regardless of its initial design's intentions, if it does what I need it to do, where is the downside?
Please approach this "question" as if I am a complete newbie. I have realized as I've gone through this process and research, that I have very large dearths of knowledge in regards to the front-end side of things. With that being said, be as specific and thorough as possible in your answers, please. I would be happy to share project configuration and such, as needed, in order to help paint a picture of the space I'm in. Thanks for any feedback!
Bower and NPM do work differently.
NPM is very powerful and great at what it does. However, you won't find many client-side packages in there; most of them are there because they work in Node too. (For example, Underscore.JS and the JADE template engine.)
That's why you have Bower, which has the majority of the client-side packages. It has many jQuery plugins, templating engines, CSS frameworks, etc. Don't expect to find such packages in NPM.
You can work fine with both. I do so. :)
Traditionally, many web development projects combined npm and Bower. npm was used to manage back-end dependencies, while Bower was used for front-end dependencies. In fact, you needed to use npm in order to install Bower in the first place.
Although Bower’s advantages were compelling, they are now provided by other tools, namely npm, Yarn and webpack. While the open source project is still maintained, its creators decided to deprecate it, and advise how to migrate to other solutions—namely Yarn and webpack.
more explanation