DEV Community: Ellie Manifold

How to write your own JavaScript tests

Ellie Manifold — Tue, 28 Jan 2020 15:15:48 +0000

While testing frameworks like Jasmine or Jest are commonly used for JavaScript, it is sometimes useful for beginners to write their own tests for JavaScript. The reason that we were instructed to do so at Makers is to gain a better and more rounded understanding fo what testing frameworks actually are. They are not 1000s of lines of mysterious code that miraculously 'does the job', but instead the foundations are based on simple and understandable logic.
To begin, it is preferable to create an assert variable in a separate assert.js file. This will contain the following code:

var passedTests = 0;

var assert = {
  isTrue: function(assertionToCheck) {
    if (!assertionToCheck) {
      throw new Error("Assertion failed: " + assertionToCheck + " is not truthy");
    }
    passedTests++;
  }
}

This assert variable can be used against what you're testing, to decipher whether the statement you're testing 'isTrue' or not. The passedTests variable allows you to see in the browser, when you eventually open the console to run the tests, to see how many tests are passing. Each time a test passes, this variable is incremented by 1.

Then create a separate test file for each js file you will create. If you're following a TDD process, you'll want to write the tests first. For example let's create an addition-test.js file in a spec directory within your main project, and put in the following:

function testAdditionAddsNumbers() {
  assert.eq(2 === addition(1, 1));
};
testAdditionAddsNumbers();

Then, we'll create an addition.js file in a new src directory, with logic that on the first attempt will be wrong so we can demonstrate the error.

function addition(num1, num2) {
  return num1 - num2
}

Now, let's create the test-suite.html file that will link the tests and code together. This can go in the root directory of your project, and should have the basic HTML structure with script tags in the body. These should have a src attribute, with the path to the test file (and separate script tags for the js file and assert file). The test script tag will have to be below the js script tag, so the tests have access to the code. You will also need to include a script tag console logging the passed tests, so you are able to view that variable.

<!DOCTYPE html>
<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <title></title>
  </head>
  <body>
    <script src="src/addition.js" charset="utf-8"></script>
    <script src="spec/assert.js" charset="utf-8"></script>
    <script src="spec/addition-test.js" charset="utf-8"></script>

    <script>
      console.log(`${passedTests} passed tests`);
    </script>
  </body>
</html>

Now we've got everything set up, run $ open test-suite.html on your command line. This will bring up the page in chrome. Open the developer tools console, where, because of the incorrect js code, it will throw an error as show below.

So, let's go back and fix this error so that all of our tests are passing.

function addition(num1, num2) {
  return num1 + num2
}

Refresh the test-suite page in chrome, and you will no longer see the error, with one test now passing.

To increase your test suite, simply create more js files and test files, inputted as script tags in test-suite.html.

Group Project - MakersBnb

Ellie Manifold — Fri, 03 Jan 2020 15:35:04 +0000

In Week 6 we did our first group project, with the aim of building an AirBnb clone - MakersBnb.

On the Monday morning, we were randomly assigned our groups for the week, and we went away to form a plan with some goals. This is what we decided:

Stand up every morning, 9:30 - setting goals for the day, talking about any possible blockers for the day, what do we expect from the day, where we’re all at with our individual sections
Retro at the end of the day around 5/5:30 (means we can go back and work afterwards if needed) - discussing what we’ve done each day and how well we’ve achieved the goals that were set in the stand up
Midday reflection each day
Pairing as we’re at a team of 6 - starting with pairing with the same people all week, and if this doesn’t work we can be flexible and change to either switching pairs daily or working individually
Before we start the project, break the project down and think about what each pair is going to be doing. Allocating a section to each pair, making sure we have a solid structure
Communicate, make sure if you have any problems vocalise them
Will discuss preferences, what each pair would like to do within the project
Any possible blockers, not being able to progress on certain parts of the project. If a pair isn’t able to move on, discuss how we will go about rectifying this
Make sure we’re really strict with the stand ups and retros

We then got going with the planning which included user stories, relationship diagram, and writing up a flow on the whiteboard of what we wanted the flow of the program to look like. This was what we decided we wanted for the front-end:

We decided we wanted to write the code in Ruby, tested with RSpec, as we did not believe we would have time during the week to take on a relatively new language (JavaScript) and link it to a new server and database. Ruby would produce better results at that point.

As we were a team of 6 we were able to have three pairs, and went about assigning each pair a section of the project in order for us to reach the goal of having an MVP by the Tuesday evening. My job with my pair, Julie, was to write the code for the Listing class. The other pairs would create the basic website structure using HTML, and create a User class.

By Tuesday evening, we had the MVP up and working as we did a loose version of mobbing on Tuesday to link up each class with the controller and the front-end.

Over the next few days we discussed a task for each pair in the morning stand up (either fixing a bug or advancing the program), and we would discuss the progress that we made on these either during the afternoon reflection or if it was a longer job that could not be completed in half a day, in the evening retro.

By Thursday evening, we had a fully-functioning site that allowed the user to login/sign-up/post a listing/view all listings/book a listing/view their booking confirmation. However, the site that we had at the moment had no CSS to it, which is a job that we undertook on the Friday once all the functionality had been done.

We ended up with a nice looking final product which we were all happy with, which worked well as an AirBnb clone. There are many things that could be developed, such as adding request/response functionality in order to book a listing. Overall, I really enjoyed my first group project!

Web apps: Battle and RPS

Ellie Manifold — Mon, 02 Dec 2019 17:20:08 +0000

This week we were looking at web apps, which involved creating an app hosted on localhost with Sinatra and tested with Capybara, using RESTful routing and MVC (Model/View/Controller structure).

This was the week that I enjoyed the most so far, as there is something so satisfying about seeing your code come to life in a more 'physical' sense than simply running the program in IRB. Over the last few months I have been leaning heavily towards front-end development as a career path within software development, and this week was a great continuation of the knowledge I had built from my previous independent projects.

Our afternoon challenge consisted of making a 'Battle' game, using Ruby, HTML, and some CSS. This was actually a more difficult challenge to complete than the weekend challenge. The premise was that each player attacked the other, and when they did so the opponent lost 10HP (hit points). While I completed the functionality, unfortunately I did not have time to do any CSS, so I will try and revisit this in future weeks if I have time.

The weekend challenge was my favourite so far. We built a game of Rock, Paper, Scissors, again using Sinatra and Capybara with Ruby, HTML and CSS. This was similar to the Battle app that we did during the week.

Something that I'm struggling with and was prevalent this week is to always stick to writing my tests first, before I touch on writing any code whatsoever. Personally, I begin to understand the task so much more after I begin writing the code and it starts piecing together in my head, so only after this I know what to write tests for. This means that I accidentally start writing the code while I'm trying to work out what to test for, and before I know it, I've reversed the order that it should be done in. I have found that there are quite a few people in our cohort that have this problem. However, I discussed this with a coach on Friday who suggested 'spiking', the idea of writing a part of code first in order to know what to test for (if you're unsure), deleting it once you've worked this out, and then writing the tests. I'll try this in my future work, hopefully it'll solve my problem.

In Theory But Not in Practice

Ellie Manifold — Tue, 19 Nov 2019 19:10:22 +0000

We've officially completed our first week at Makers! One down, eleven to go. It's been as rewarding as it has been tiring, but I do get the feeling that we're still in the honeymoon phase.

Something that I did find I struggled with this week was my learning strategy. I found that, during the pair programming challenge in the afternoons, I would be having trouble using certain aspects of code that I previously thought I understood. This was the case with attr_reader, attr_writer, and attr_accessor. While I was aware of the theory behind these concepts (as I had acknowledged it as a gap in my knowledge and 'learnt' it the week before (and could explain its function to other people)), I had a difficult time with them when actually having to implement and use them within my code. This occurred on more than one occasion during the week, where I struggled using concepts in practice that I technically understood the theory behind.

To me, the solution in order to resolve this in future was fairly simple. My goal over the next few weeks is, when learning programming principles, to not only begin by reading through documentation and articles, but follow this up with practicals and exercises that include the area/s I'm struggling with. Makers have many online resources so hopefully I should be able to begin by finding help there, but if not, I can try googling or making up my own exercises.

Onwards and upwards!

Overcoming a Fixed Mindset

Ellie Manifold — Wed, 13 Nov 2019 17:54:17 +0000

I was coasting. And I knew it. I had been working in marketing for over a year, and still hadn't found much of a thrill in it. Some areas I did find interesting, however my day-to-day was not doing it for me. Having lived with two developers I had always been exposed to coding and software development, and decided to give it a try, beginning with a couple Codacademy courses. Enjoying this, I moved on to more substantial resources, including Free Code Camp and a lengthy Udemy Course where the end product was your own fully functioning website.

So, I knew this was a field I was interested in , but I couldn't possibly go forward with it as a career... could I? To anyone looking from the outside in, CS is such a foreign concept. Quite literally a different language. As most are aware, Imposter Syndrome is so prevalent among those attempting to begin their journey in the industry. I only realised I wasn't alone in feeling like this when I began researching online and listening to podcasts about how to get into programming, hearing about other people's experiences.

This was only reinforced by my inherently fixed mindset - what if I didn't have the programming 'gene'? As a female entering a male dominated field, this was a difficult feeling to overcome.

However, things soon changed. When I decided to undergo the course at Makers Academy and began the pre-course, I came across the article 'Effective Learning Strategies for Programmers' by Allison Kaptur, describing the issues people undergo when faced with a fixed mindset verses a growth mindset. Previously I wasn't even aware of the concept, let alone that it is in fact what I had been experiencing.

This is the point where my whole outlook changed. I had been actively holding myself back - entirely unnecessarily. Once I realised that a growth mindset was something to aim for, I made the active decision to eradicate the state of a fixed mindset from my thought process.

Since then, whenever I'm struggling to understand a problem or fix a bug, I make an effort to push these 'dead-end' thoughts from my mind, and think about how the solution is to just keep working at it. There is no such thing as 'not being good enough to program'. While it's easier said than done to just magically change your entire way of thinking, I did begin to allow myself to fully enjoy the tasks I had at hand, as, in the end, they inevitably will be resolved. The problem became significantly more enjoyable as I could now look forward to the inevitability of eventually solving it, instead of exacerbating my immediate frustrations with the idea that 'I can't do it, it's impossible, it will never be done'. I just had to remember; it will all work out in the end!