Unit testing javascript (NOT node) - javascript

I am scratching my head at this one, I must have missed something really obvious.
I have a .Net ASP MVC Web app, developed with VS2015, in which I have written some library javascript code. I would like to have some simple tests for this javascript code that I can run in my dev environment, on my own machine. I have no IIS server locally. (The server side code is fine, I use NUnit and VSs Testrunner).
I have read about Mocha (and used it back end), QUnit etc - but anything whose installation and use instructions start npm install and talks about running grunt jobs is not what I am after.
Can someone point me in the right direction / educate me?

If you are up for using pluralsight, it is what got me started. There is a free trial and quite a few videos on testing mvc.

Related

Does Running Node Locally Differ From Installing Node on the Web Server?

I'm wondering in principle how node.js works on a website that's running node code. I'm new to programming but I did manage to get node installed to practice with Angular and some Nodeschool stuff, however I don't think this is actually the whole story because the web server needs to have node and npm (maybe nvm) all installed in order to actually use any node code. Or am I misunderstanding how node works?
I guess I'm really looking for an understanding of the whole application of the node framework; what am I actually doing by running a practice program like the "Tour of Heros" Angular tutorial on my local machine, just testing it locally right? Because if I actually wanted it on my website I'd need to install node there and then run the framework on the server, from what I can gather...
Thanks for your time! I hope I made my confusion clear enough.
Angular tutorial by Google "Tour of Heroes"
Node and JavaScript are different. Node provides a runtime environment enables JavaScript code to be executed outside browser. It provides various native libraries and event loop allowing main thread of execution to perform asynchronous operations.

Electron for only front end

I am trying to make my web application into a desktop app. I have already built and configured a server to host the backend scripting written in python.
My front end is written in JS, JQuery, HTML, CSS.
I have found an open source framework called Electron that packages web apps into desktop apps. Can I implement this so that it only wraps around my front end components without having to alter my back end server?
In essence, yes you can use your current web code to create a desktop app using Electron, as Electron in essence is basically just a simplified browser. However, you will need to add some things to your project if they don't already exist in order for Electron to work.
3 things in particular:
(See the quick start guide: https://electron.atom.io/docs/tutorial/quick-start/)
package.json
main.js
index.html
You'll also need nodejs installed as electron itself is an npm module.
So not quite as straightforward as you may have thought but definitely a fairly simple and viable approach.

Running Jasmine testing on Ubuntu. Page not found

I installed Jasmine-gem on my project without rails usage as my app is php based on Ubuntu. I go to localhost:8888 as said and get page not found in any browsers. Am I missing a basic HTML page like the standalone install or something?.
I know this isn't a full gems issue because compass and other gems function fine.
Can't figure out what I am doing wrong, it is able to find the specs in the command line.
I could just load jasmine standalone but if is possible to get this running, I would really appreciate it!
Thank You.
Forgot to mention I am running Windows. Since Jasmine will run on its own server, I installed it directly on Windows and it works fine. Thanks again for your help. Sometimes you wonder which way you want to go on a shared file system.

What is Grunt for?

I'm trying to get into Grunt, which I am new to, but I do not understand its utility.
I understand that it is a taskrunner. I understand that it can be used to do things like bundle, uglify, jshint, minify, etc etc etc, anything that can be turned into a scripted task.
But I don't see what advantage this gives. Nearly all of these can be run from the command line anyway, which is to say you could just combine them using a simple shell script. It seems to me that setting up grunt + gruntfiles and writing tasks is more work than writing a shell script, rather than less.
What am I missing about this?
Grunt is basically a build / task manager written on top of NodeJS. I would call it the NodeJS stack equivalent of ANT for Java. Here are some common scenarios you would want to use grunt under:
You have a project with javascript files requiring minification, and generally generating a front end build seperately (in case you're using say JAVA for your backend). (grunt-contrib-uglify)
When you save code on your machine during development, you want the browser to reload your page automatically (might seem like a small thing, but believe me this has saved me lots of time). (Live reload)
When a developer saves code on his machine, he wants a comprehensive list of JS errors / general best practice violations to be shown. (grunt-contrib-jshint)
You have a project with SASS/ LESS files which need to be compiled to CSS files on the developers machine during development, For example whenever he saves a SASS file, you want it to be compiled to a CSS file automatically, for inclusion in your page. (grunt-contrib-sass)
You have a team of front end developers who're working on the UI, and a team of backend developers working on the backend, you want the front end devs to use the backend REST API's without having to compile & deploy code everytime on their own machines. In case you were wondering, this isn't possible with a typical web server setup because XHR isn't allowed to be cross-domain by browser. Grunt can setup a proxy for you redirecting XHR requests on your own system within the grunt connect server to another system! (grunt-contrib-proxy, grunt-contrib-connect)
I do not think your shell script can do ALL of these. To summarize, yes, setting up a Gruntfile.js is tedious for someone who has had little exposure to javascript / is new to nodeJS, I went through the same pains as a learner, but Grunt is an amazing piece of software. DO invest the time to setup a proper Gruntfile.js for your front end project, and you'll thank god for making your life a lot easier :)
The Advantage vs shell script:
If you write shell script for every one of these tasks, it is tedious to maintain and then customize for every one of your needs. Gruntfile.js is actually pretty easy. there is a config that you init it with, specifying what tasks you want to perform, the sources and targets for each.
The integration with project seed generators on Yeoman, Gulp is another major factor to consider. Yeoman and Gulp come with Gruntfile.js' with intelligent defaults. For someone who is the sole UI contributor on his team, this is priceless to me!
For someone who is working on frontend technologies, if you have more than one person working with you, its rather easy for them to get to know Grunt, which is already well documented with a lot of answers on SO, than to get to know your shell scripts. This might be a factor in large teams.
The numerous plugins for Grunt extend base functionality. Unless your shell script is VERY popular, and VERY modular, I dont see plugins being built for it. This also extends to inclusion of new front end technologies in your project. Say, if you want to use typescript in your project tomorrow, your shell script will need to incorporate this and account for it with your own effort. With Grunt, its just as simple as "npm install " and adding a config.
Even though I agree with most advantages pointed in Accepted Answer, I still have to consider the disadvantages that are highlighted by Keith Cirkel in Why we should stop using Grunt & Gulp
Thus, some advantages are rebut by Grunt overheads and at least you should consider all this in your final decision of using Grunt, or not.

Why do frameworks and git hub ask you to use Terminal?

I'm a newbie and that's ok.
But when I use tutorials, they always tell me to go straight to my terminal and install documents from there in which I have no clue what the next step is and no idea why I have to do it. Is it essential that I install frameworks through terminal or can I just work without it?
ex. http://net.tutsplus.com/tutorials/javascript-ajax/real-time-messaging-for-meteor-with-meteor-streams/
"Let’s create a very simple, browser console based chat application with Meteor Streams. We’ll first create a new Meteor application:"
meteor create hello-stream
I understand this is may not be very challenging, but I don't have a clear answer when I try and simply google it. Anything would help, thanks a lot!
Being a newbie is ok.
The terminal is the go to because writing programs, tools, and scripts with a couple lines of bash or python is, well, a couple of lines versus an entire gui and all the lines of code to go with it.
meteor create hello-stream
That's telling you to run the program called meteor with the supplied arguments (create hello-stream).
If you haven't installed meteor, do that next. From their website, open your terminal and type/paste:
curl https://install.meteor.com | sh
That downloads a file from the URL and pipes (|) it to the sh command. The file it downloads is a shell script that takes care of setup/installation. Now go back and try the meteor command again.
More reading
You might try and find a terminal tutorial. This is the first one I found:
http://www.ee.surrey.ac.uk/Teaching/Unix/
Answer from someone who only recently (as in: within the last year) got into using the Terminal more and more frequently:
It's generally a good idea to get used to using the Terminal for code-related things as you can pretty much use it platform-independently (meaning you can use the same commands on Mac, Linux, Windows,...) and because it makes you understand better what you're actually doing.
Once you've got the hang of it, it can make navigating your system as well as making changes to it easier. Hidden files, for example (like .gitignore files, or files in your .ssh directory, or your .bash_profile), can be viewed, opened and edited easily from the Terminal whereas you have to take multiple, complicated steps (or install other software) to view them from your Finder.
With the help of package managers (like Homebrew), which are also operated from the Terminal, you can also install software that isn't otherwise available for Mac.

Categories