How do you set up things like linting and testing for backend projects? Can you use webpack as a task runner for this?
Depends on which technologies you’re using. Ruby/rails automatically sets this up for you. C requires external libraries. Rust does this automatically. Node needs libraries like Mocha/Chai, you can find instructions about how to install it in their documentation/github pages.
Nope, webpack deals with front end automation, basically.
It’s important to understand the difference between front end and back end. Every web server serves files at a very basic level, some of these files are dynamic and generated automatically, this proccess is the bulk of back end development. You define routes, write scripts, talk with databases and edit files. None of these things are possible (under normal circumstances) on the front end.
TL;DR:
- decide which backend technology you’re going to use
- Just look for tests for that technology, you will probably very easily find a way to test your application. If you’re using Node for the back end, i recommend Mocha and Chai.
I forgot to mention I’m using nodejs. I guess I’ll check out gulp then.
Gulp is also a front end tool. You need to research about unit testing and integration testing for nodejs.
To clarity, tools like mocha and chai already do the job of running a batch of automatic tests. They’re literally made for testing. There is no need to use another automation tool on top of it.
As i mentioned, you need to research about testing itself, not tools.
Ok, how can you automate testing? Say, I’m gonna use mocha and chai to test. I’m aware that you can test with mocha via the command line, but I want the tests to run when I make changes to my files.
Edit: Scratch that. Just looked at the mocha docs, and it looks like there’s a flag for watching file changes.
I have not used Gulp with Node, but why can’t you use it on the backend? It seems to me that Gulp with gulp-eslint and gulp-mocha should be able to work regardless of the JS files being Node instead of normal JS.
The watch flag is good for while you are developing.
You might find something like TravisCI helps with your deployments.
With a little script like the one below, I was linting and testing all deployments for Pairboard whenever a pull request was merged:
{
"language": "node_js",
"services": "mongodb",
"node_js": 6,
"cache": {
"directories": [
"node_modules"
]
},
"script": [
"npm run first", // <-- Note, this was a custom script
"npm test",
"npm run build"
],
"group": "stable",
"dist": "precise",
"os": "linux"
}
Travis basically spins up a Linux instance, and runs whatever you tell it to. So you run everything someone forking your repo would do on their machine to get it up and running (that’s what npm run first does in my example), and then you run your testing / linting.
If it falls the test, Travis borks the deployment 
And it’s free for non-enterprise users 
1 Like
I tried travis ci to deploy my last few projects to surge when I push to the master branch, and it’s way awesome and better than my previous setup (using git-scripts to deploy to surge whenever I push to whatever branch). It’s a pain at first, but I’m more or less comfortable with the thing now.
Why do you need that, though? I can see why linting would be essential upon file change, but testing seems like a very strange decision.
Usually to make a test work you need to think a lot about it, change or create a lot of files. Do you really want a red warning upon each file saved to tell you the tests aren’t passing?
I say that because maybe you have a misconception about what back end tests do. It’s not something you’re supposed to run hundreds of times upon small file changes, so that’s why it’s often times not automated in the same way linting is. That’s why i think it’s important for you to read about unit and integration testing. Mocha and chai are already tools of automation, they automate the task of testing your application for you.
Otherwise, you can probably use gulp or webpack to run your testing script upon file change. Just find a way to trigger the command line command for running all your tests.
I had never thought about it, but it seems to me as if that would be a misuse of the tools available. You can certainly create a testing pipeline with webpack too, the tool gives you the ability to do that. But the question here is if you’re not spending a lot of time to make a tool do something that it wasn’t made for.
I can see gulp and webpack being capable of handling tests. I just can’t see where that would be useful as a usecase, specially for beginners. Seems like a lot of work for very little time saved.
2 Likes
Yeah, I do. Thanks for clearing that up.