Introduction to the Tutorial
Many people I talk ask, “How do I get started doing X“. I point them to doing projects that solve problems, like I mentioned in my first post here. There’s not feed back as to if that advice helped them or not. That brought about this tutorial.
This post, specifically, won’t actually be the tutorial. Over the course of this post, I’m going to write about unit testing, end to end testing, TypeScript, etc. You’ll probably get bored, but stay with me and by the end you’ll have made a highly tested and functioning web To-Do App. If you do get bored and wander off, I’m sure you’ll figure a lot of this out on your own in time. A To-Do App isn’t hard by itself.
Note on Tutorial Expectations and My Style
First thing to say is that my style probably isn’t for everyone. I will state my opinion, jokingly, like its fact. I will pick on, possibly, your favorite language. There are other things that you possibly won’t like either, just keep in mind, you clicked on my post.
This tutorial expects you to have an understanding of programming. It, of course, doesn’t expect you to be a grand master of the code, but at least have seen some in your life. It would really benefit you to go out and buy a few books and maybe read them as the tutorials come out and you expand on this project. Clean Code, Practical Test Driven Development Using C# 7 and Clean Coder; read those and get back to me.
There are definitely more books that you could read, but I don’t really want to bog down this post with literature suggestions. Instead I’m going to go on listing the other things this tutorial expects:
You should be able to open your command line or at least use google to look up how. You should have or go download MongoDB now for your computer. If you can’t download it, you’re a little out of luck. It’s a big part of the whole project. That ‘M‘ in MEVN stands for Mongo… So I’d say that it’s worth at least 25%.
Why a To-Do App
Great question internet, honestly. I have enough time to explain it if you have enough time to read it. The reason for doing a To-Do App is because a To-Do App is the “Hello World” of Single-Page Applications (SPA). Honestly it’s the “Hello World” of JavaScript/TypeScript full stack applications.
The reason that the To-Do App is such a big deal for this thing is one word: CRUD. A To-Do App, typically, covers all of those letters. A To-Do App will create a To-Do, read a To-Do, update a To-Do, and then delete a To-Do.
The work flow goes something like this: A user creates a To-Do that they want to get done. If they see they mis-typed the To-Do, then they change the To-Do and update it in the system. Each time the user logs into the app, they are returned back a To-Do that they have to get done. Then finally, once it’s completed they delete said To-Do.
The same can be said for a Reactive Single-Page Application for the frontend. The user wants their actions with the model on the backend to be reflected on the frontend. We do that in the same manner as the above, but often in different ways depending on how we want the app to function.
What Is MEVN
A MEVN app is a full stack application stack that stands for: Mongo, Express, Vue, Node. It’s a stack fully written in JavaScript (yes even though we’re writing in TypeScript). Mongo is the database, Express is the router and web sever for the app, Vue is the frontend and Node is the tool that allows us to run TypeScript/JavaScript outside the browser. Neat stuff.
On top of all that we’ll be using some other tools that will be helping us along the way. Jest is a unit testing framework that we’ll be using. This has been chosen over Mocha/Chai because honestly Mocha/Chai is garbage. Yeah, I said it, fight me. But I won’t just say it, I’ll back it up.
The first reason why Jest is better than Mocha/Chai is because it comes ready with small configuration for an HTML coverage collector. With Jest, all you have to do is go into your jest.config.js and it add coverageReporters part with the right arguments (we’ll go over this later). And there you go, now you have reporters that display your code coverage.
Second reason is that Jest has, in my opinion, better set-up an tear down for each test. This is done through the use of their beforeEach, afterEach, beforeAll, etc. This code gives us a change to set things up before each test in the blocks and make sure that we’re setting things up properly before hand, and removing unnecessary things afterwards.
The Next Part
The next part should not take much longer than this article to come out. The next part is going to go over setting up your Node Development Environment and setting up your node project with Jest, Mongo and Express.
