DEV Community: Katie N

Setting up test files in React with Jest

Katie N — Thu, 29 Feb 2024 20:25:52 +0000

When creating applications, a skill that will help create scalable and properly working code is the ability to write tests. Unit testing allows us to test the individual functionality of our React components. Learning how to write tests can be instrumental in debugging quicker and writing good dynamic code. In this post we're going to talk about how to use Jest testing framework with React. If you're familiar with React, you know how powerful and intuitive it is. Well, Jest is just like that - powerful and intuitive. We will be using the Node package manager for this blog but yarn works similarly.

Getting Setup

When starting a React project, a popular way to go about it is to run npm create-react-app. Starting your repo with this command will automatically install Jest so there is no need for any extra install/download work. Double check your package-json folder to make sure you have the proper packages installed. If it is not already installed you can run npm install --save-dev @testing-library/react to install.

  "name": "client",
  "version": "0.1.0",
  "private": true,
  "proxy": "http://localhost:3000",
  "dependencies": {
--->"@testing-library/jest-dom": "^5.17.0",
--->"@testing-library/react": "^13.4.0",
--->"@testing-library/user-event": "^13.5.0",
    "bootstrap": "^5.3.3",
    "react": "^18.2.0",
    "react-bootstrap": "^2.10.1",
    "react-dom": "^18.2.0",
    "react-router-dom": "^6.22.1",
    "react-scripts": "5.0.1",
    "web-vitals": "^2.1.4"
  },
  "devDependencies": {
    "@babel/plugin-proposal-private-property-in-object": "^7.21.11"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
--->"test": "react-scripts test",
    "eject": "react-scripts eject"

You can see under our "dependencies" there is the Jest package installed and the "test" line in our "scripts".

Test Structure

The best way to set up your test files is to create a folder in your /src folder and name it __tests__. In this folder you will keep your test files. When you create your file, the best practice is to name your test file almost identical to your component file name. For example, if we were going to start writing tests for our App.js file, we should name our test file App.test.js.

Navigate to App.test.js and in the top of the page import the libraries you need for testing. It will typically look something like --

// import libraries needed for testing
import "@testing-library/jest-dom";
import { render, screen } from "@testing-library/react";
import React from "react";

// import the component you wrote
import App from "../components/App";

Often the test file will already be started for you automatically, but you should always double check.

Jest tests are written in test blocks. They consist of 4 parts.

Render the component you want to test.
Find elements of the component you want to interact with.
Interact with the element and establish expectations.
Assert 'expected' results.

For this example, let's use the tried and true "Hello World" example. We have a simple App.js component --

import React, { useState } from 'react';

function App() {
  const [message, setMessage] = useState('Hello World');

  return (
    <div>
      <p data-testid="message">{message}</p>
      <button onClick={() => setMessage('Button Clicked')}>Click Me</button>
    </div>
  );
}

export default App;

And then we will have our App.test.js file --

import React from 'react';
import { render, screen, fireEvent } from '@testing-library/react';
import App from './App';

test('renders the correct initial message and updates it on button click', () => {
  // Render the App component
  render(<App />);

  // Find the element that displays the message
  const messageElement = screen.getByTestId('message');
  expect(messageElement).toHaveTextContent('Hello World'); // Initial expectation

  // Find the button and click it
  const buttonElement = screen.getByRole('button', { name: 'Click Me' });
  fireEvent.click(buttonElement);

  // Assert the message has changed after clicking the button
  expect(messageElement).toHaveTextContent('Button Clicked'); // Updated expectation
});

Let's go through each section.

test('renders the correct initial message and updates it on button click', () => {
  // Render the App component
  render(<App />);

Each test will start with test() or it() (used interchangeably) to provide context around what you plan to use the test for. You can also take it a step further and include a describe() above the test() line to further describe the test or name it.

describe("correctMessage", () => {
    test('renders the correct initial message and updates it on button click', () => {
      // Render the App component
      render(<App />);

Next up we find the elements we want to interact with.

  // Find the element that displays the message
  const messageElement = screen.getByTestId('message');
  // Initial expectation
  expect(messageElement).toHaveTextContent('Hello World');

We will use screen to filter through the component and pluck out what we're wanting to test. We're looking for .getByTestId so let's look back up at our App.js file and see what is being pulled into our test.

In our App.js file we see this line --

<p data-testid="message">{message}</p>

This is what is being pulled by our test to be interacted with.
In the next line we are declaring what we initially expect from this element. We expect the message to say "Hello World".

Then we go down a little in our test and see the next expectation of our test.

  // Find the button and click it
  const buttonElement = screen.getByRole('button', { name: 'Click Me' });
  fireEvent.click(buttonElement);

Same thing as before. Pulling the element we want to test through screen and declaring our initial expectation. This is the element we are pulling this out of our App.js component --

      <button onClick={() => setMessage('Button Clicked')}>Click Me</button>

We are expecting this button to be able to do something. To click.

note: the fireEvent function is used to mimic a call to action for your test.

Once we have pulled our elements and gave them initial expectations, we're going to assert what we want our final expectation to be of how those elements tie together to do what they're supposed to.

  // Assert the message has changed after clicking the button
  expect(messageElement).toHaveTextContent('Button Clicked'); // Updated expectation

We expect our button to display "Hello World" when it is pressed.

Refactoring and npm test

Once you have your tests written you'll want to actually implement them. Assuming you have already ran npm install in your terminal, you're going to run npm test. You should receive an output of all your passing and failing tests as well as a CLI menu to be able to interact with your terminal while your tests are being watched and ran.

> your-app-name@1.0.0 test
> jest

 PASS  src/App.test.js
  ✓ renders the correct initial message and updates it on button click (32 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        1.357 s, estimated 2 s
Ran all test suites.

If you notice that your tests are failing, you will have to go back into your App.js file to refactor your code until your tests are passing. Unless you exit out of the test suite it will update and run every time you save your file.

To be able to navigate through the test suite here is the CLI menu as well.

Watch Usage
 › Press a to run all tests.
 › Press f to run only failed tests.
 › Press p to filter by a filename regex pattern.
 › Press t to filter by a test name regex pattern.
 › Press q to quit watch mode.
 › Press Enter to trigger a test run.

Conclusion

I hope now you have a better understanding of how to implement testing into your code. It is so helpful and time saving in the debugging process allowing you to focus on the creativity.

Sources

Digital Ocean
Smashing Magazine
BrowserStack
NetNinja
ChatGPT
Canvas

Basic overview for creating a stellar README file

Katie N — Mon, 12 Feb 2024 03:07:37 +0000

When you create projects that you want to show to other people you should get in the practice of creating an overview that tells people about your application, what it does, how you use it and other important information people should know before exploring your repo. The README file is typically the first thing other developers will look at when they first enter your application. Giving a good impression off your README is a great way to get other developers engaged in your project!

Getting Started

First, you want to think about why you created your application. What problem does it solve? What is the purpose of it? What does the application do?

Next, it's a good idea to use Markdown syntax to style your README. It allows you to easily format your README to make it visually easier to read and catch the readers eye more easily. It also will help in making your README look really good when it's opened in a browser window.

Once you have an idea of your "why" for the application, it makes writing the README much easier.

Structure

Title
Authors
Description
Setup/install
Table of Contents
Licenses
Extras

Title

Include the title of your project. Give it a name that is indicative of the project. You can also add a sub-heading to add any additional information in your title.

Authors

Pretty easy. Who wrote the program? Include the names of everyone who worked on the project.

Description

Give a brief description of your application. 3-5 sentences is generally enough. Most of the time people are just scanning the information to get a general idea. You can take it up a notch by adding some images of the application or any diagrams you think would be helpful to include. But keeping it relatively short is ideal.

Setup and Installation

Another top key feature to include in your README is giving the commands you need to run the application. Inform the reader of the packages and other technologies they'll need to install and start to get the application running. For example, if you were doing a README for a React/Python application, the set up instructions might look like:

pipenv install
pipenv shell
npm install --prefix client

python server/app.py

npm start --prefix client

Although you want to keep your README relatively short and simple, sometimes they can get kind of lengthy. So, some people opt to include a table of contents under the title of their README. These are optional and won't make your README any less substantial if you choose not to include one.

Licenses

When you are working on a project and you want to protect your intellectual property you can get a license to include in your README. There are different type of licenses you can get based on whether you want to have your application be an open-sourced project - where other people can fork your repository and make changes to your project. Having a license will allow you to keep that copyright and tell developers what they can and can't change in your project. Here are a couple of links to some licensing websites to guide you.
ChooseALicense
Open Source Initiative

Extras

There are some extra elements you can include in your README to take it the extra mile. Some popular ones are things like including any tests you have implemented. Creating your own tests is a really good way to show off your skills as a coder and really takes your skill set up a notch.
Another big one is including badges. Don't go overboard on the amount of badges you use as it can be distracting from the point. But including some in your README can be a really good way for anyone who reads it to take quick notes of what's going on in your application.

Conclusion

I hope these tips and links I included help give you a template of how to write a profound and informative README that will impress anyone who sees your project. As always, happy coding!

SOURCES
archbee.com
GitHubDocs
FreeCodeCamp

CRUD-DY SQL

Katie N — Tue, 23 Jan 2024 14:04:45 +0000

When coding you're faced with tons of data and databases. It can be overwhelming when you're working on projects - big or small. Luckily, there is a tool that we can use to help keep that data organized, readable, and mutable. Were going to talk about what SQL is and how we can implement it in the most basic of ways.

SQL(Structured Query Language)

-- is a standard computer language used for accessing and manipulating databases. SQL creates tables for our data and allows us to be able to reference it and change it as needed. The basis for SQL is the Relational Database Management System or RDBMS for short. It's the program that manages our data and we use SQL to talk to the RDBMS so we can stay on top of our data.

Like most coding languages, CRUD (Create, Read, Update, Delete) is essential for being able to interact with the data that you are working with. SQL is no different. Let's dive into the CRUD actions step-by-step to get started using SQL.

CREATE

In SQL the "Create" is initialized with the INSERT INTO method. It is a two-step command. In the first part you'll include the table that you're calling upon and the sections of that table you want to add to. The second part, the VALUES, are the actual input you want added to your table. For our example were going to imagine that we are programmers for Spotify and we are in charge of editing playlists.

Hypothetically, we can do this using SQL. We want to add a new song to the playlist so we can do it like this:

INSERT INTO ThrowbackThursday (Title, Album, Date Added, Time) VALUES('Picture feat. Sheryl Crow', Cocky, 5 days ago, 4:59);

and our play list should look something like this --

READ

In order to perform a 'read' action in SQL you use the command SELECT. SELECT statements work in a two step system just like the INSERT INTO method.
SELECT <name of column> FROM <table that contains the column>;
So, going back to our playlist from earlier we could do something like --
SELECT id, Title, Album FROM ThrowbackThursday;

And this should return your data in a nice table.

1 | Every Morning | 14:59 
2 | Follow Me | Double Wide 
3 | One Week | Stunt(20th Anniversary Edition)
etc.

There are ways to build on this initial statement with other conditions to return more specific data as well.

A way to get ALL the data sent back to you is to use "*" aka the 'wildcard selector'. Using the asterisk as your selector tells SQL to give back all the data from the table called on.

SELECT * FROM ThrowbackThursday;

UPDATE

To update your data using SQL you'll use a statement with the basic syntax similar to this.

UPDATE <table name>
SET <column name> = <new value>
WHERE <column name> = <old value>;

To do this in our playlist example we can do something like

UPDATE ThrowbackThursday
SET Title = "Walkin' On The Sun"
WHERE Title = "All Star";

DELETE

The final part to cover for our CRUD actions is the DELETE statements. It is a similar function to how we do the UPDATE function. A basic example would be:

DELETE FROM <table name>
WHERE <column name> = <value>;

Touching back on our playlist, we would have something like

DELETE FROM ThrowbackThursday
WHERE Title = "Tubthumping";

CONCLUSION

I hope after this post you feel ready to dip your toes into the world of SQL.

SOURCES

W3 Schools
W3 Schools
Canvas
SQLShack

A Collaboration Guide to Github

Katie N — Tue, 02 Jan 2024 03:43:35 +0000

When working on a programming project, you'll more than likely use Github. A cloud-based Git repository hosting service that makes it easy to use Git for version control and collaboration.
Working and collaborating with other team members during projects is a common practice in software development and having a clean flow of who is in charge of what, is so important. Let's talk about some good Git practices to use to get into an organized and efficient work flow.

BRANCH OUT

One of the "golden rules" of collaborating is to create a new branch off the default Main branch. If everyone is writing code on top of each other in the same branch, it can cause unnecessary extra work, create bugs, and maybe even break the code. When you create your own branch you are able to test your code before submitting it to the main branch and ensure it works.

It is best practice to create a new branch from your forked and cloned copy of the repo, after you finish your portion of the code, then push it up to Github to be reviewed and then merged.
To create your own branch you can enter the following into your terminal and it will create and direct you to your new branch:
git checkout -b <NewBranchName>

After you get done with your code, you want to add the new changes by running:
git add .

Then, you'll want to run a commit command:
git commit -m "message with what is being committed"

Once, you've done that and you're ready to push up your branch you'll run:
git push origin <NewBranchName>

When you go back to your repo on Github you should see the newly added branch and an alert with a button to "compare and pull request". Click it and sync your new branch with your repo.

Hopefully, so far this is something you're already familiar with. In the next part, we're going to talk about how to merge all the work you've just done into your main branch to be put together.

Pull Requests

Pull requests are when the collaborating really starts to come together. In Github there is a tab to start a pull request. A pull request is important for two reasons.

It allows your fellow collaborators to review and discuss your branch before it gets committed to the main branch.
This request is also how you will merge your new branch into the main branch.

Merging 101

The above is an example Github page that shows the steps of how to merge those branches as well as leave comments about the branch that's intended to be merged. Let's go over it.

Create the pull request.
Leave any comments or overview of what is being added.
Go to the "Files Changed" tab to review the files that have been changed.
Check to resolve any merge conflicts and complete the prompts to merge the pull request.
Once your merged branch has been confirmed successful, it is typically best practice to delete that branch. You can do this by running git branch -d <NewBranchName>

Okay, let's go over a scenario.

You're working on a group project and you have already successfully merged your branch in Github. Now it's time to work on a new branch but once you open your Visual Studio Code you'll notice that it doesn't have your newly merged code added. To pull down your newly merged code, you're going to direct yourself to your main branch. Then run the following: git pull origin main
This will pull down your newly updated main branch you just merged.

Conflict Resolution

To prevent merging conflicts with your branches it is important to make sure that you use your main branch for merging purposes only. Try and not make edits directly in your main branch if you can help it. Why is this best practice? Because in the case you create a new branch, add some code and commit, then go back to the main branch, add some code and commit, when you go to merge you will get an alert to resolve the conflicts. This creates confusion because now there will be changes on your main branch that won't be on your new branch you just made.

Now sometimes things happen and you get merging conflicts.

IT'S OKAY!

With a few steps you can fix it.

Click the "command line" on the prompt in Github.
Ensure your main branch is up to date in your repo. To do this, run git pull origin main in your terminal.
Switch over to your new branch and run git merge main to merge the new branch into main.
You will be prompted to resolve the conflicts. You can find instructions on how to merge those conflicts here.
After you have resolved any conflicts, you'll need to re-push your new branch.
Navigate to Github and refresh the page and you should now be able to merge in your new branch successfully.

As you can probably assume, that can get tedious quickly.

Following clean Github flow and having great communication with your team mates will help keep you from doing unnecessary work.

Happy Coding!

SOURCES:
Flatiron Canvas

Kinsta

GitHub

A Beginners Guide to HTML

Katie N — Sat, 02 Dec 2023 23:18:21 +0000

As a beginning software engineer, it's essential to understand the basic concepts first to be able to utilize the power they hold. One of the main concepts to understand early on in your journey is the HyperText Markup Language or HTML as it's usually referred to.

What is HTML?

The formal definition of HTML is a descriptive language that specifies a webpages structure. HTML is a document-based technology. Which basically means that our HTML file will hold all our information for us while we build our webpage! Pretty neat.

HTML Structure

Here below is an example of a basic HTML file structure. Take a look and then let's talk about it:

<!doctype html>
<html lang="en-US">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width" />
    <title>My Example Page</title>
  </head>
  <body>
    <img src="(insert URL link for image here)" alt="Example Image Title" />
  </body>
</html>

Before we get into all the HTML tags and what they mean, take a peek at the way the the page above is structured. Easy to read and organized, right?

Keeping your HTML page clean, organized, and easy to read will help prevent any errors along the way as well as help debug and edit.

Now, let's get into it:

<!doctype html> -- This is an important line of code. It is required at the beginning of your HTML document to ensure your HTML does what it's supposed to.
<html></html> -- As you can see, there is an HTML tag at the second line of the code, and at the end of the code. This is the basic format of most HTML tags. To have an opening tag <> and a closing tag </> with your code in between. The HTML tag specifically is known as the "root" code. Within the HTML tag you will input your content. In the opening of this tag you will also put the language you will be using for your document.
<head></head> -- The head tag is where you add information to your page that is not seen by the user. Things like your CSS styling attachment, key phrases that we want to be used in web searches, page descriptions, etc.
<meta charset="utf-8"> -- Between our header tags, there are usually two standard lines of code. This is the first one. It's an element that declares the character set you'll be using in your document. Its value should be set to UTF-8 - a variable-length character encoding standard used for electronic communication - to ensure it will handle any text content you add.
<meta name="viewport" content="width=device-width"> -- Now this is a cool line of code that is the second part of our standard header element. This line of code basically will make sure that the content will render to the browser you're using.
<title></title> -- Title element is pretty easy - what is the title of your page? The title appears in the browser tab when the page loads.
<body></body> -- The body code. This is the meat and potatoes of your HTML code. All the elements the user will see will be included in the body tags. Things like text content, page headers, music, videos and images, and so on. In the body element you really get to play around and have fun!

Useful Tags

Now that we've gone over the basic anatomy of HTML pages, here are some tags you should get used to using right away:

Headings

<h></h> --Not to be confused with the header tag that we previously discussed, this tag creates a heading for your webpage that the user will see. It can be used up to 6 times but generally most developers stick to 4. Like this:

<!-- 4 heading levels: -->
<h1>My main Heading</h1>
<h2>My first sub-heading</h2>
<h3>My sub-subheading</h3>
<h4>My sub-sub-subheading</h4>

Paragraphs

<p></p> -- This is where you will include your text content that will be displayed on the webpage.

<p> Hello, my name is Katie and I have 4 dogs</p>

We can even take this a step further by adding lists to our paragraph tags by using the <ul></ul> (unordered list) or <ol></ol> (ordered list) tags.

<p>Hello, my name is Katie and I have 4 dogs</p>

<ul>
  <li>Clementine</li>
  <li>Cookie</li>
  <li>Denver</li>
  <li>Bulleit</li>
</ul>

<p>It's a dog gone paradise!</p>

Images

<img/> -- Below is an outline of how you'll add your image to your page. The image tag is one of the few HTML tags that does not need an opening and closing tag. Instead, it is self-contained. In the src attribute we add our image URL, and the alt attribute is to include any specific text related to the image that will help people who are visually impaired be able to understand the image more clearly and in the cases where your image is having problems being displayed.

 <img src="(insert URL link for image here)" alt="Example Image Title" />

Links

<a></a> -- The "a" that we use in the links tag stands for "anchor" and this one is a bit trickier than the others. To embed your link properly you'll need to follow a couple steps. First, we'll add some text to our anchor tag, like such:


`<a>Katie's Dog Blog!</a>`

Then we add an href attribute to our opening tag which will include the link we want to input.

`<a href="(URL link to webpage you want to include in your HTML)">
  Katie's Dog Blog!
</a>`

And that's it!

Conclusion

It's my hope that this post will help you gain an understanding of HTML basics and how you can use the foundation we discussed today to branch out and make some awesome web pages!

Sources:
MDN HTML Basics
UTF-8

DEV Community: Katie N

Setting up test files in React with Jest

Getting Setup

Test Structure

Refactoring and npm test

Conclusion

Sources

Basic overview for creating a stellar README file

Getting Started

Structure

Title

Authors

Description

Setup and Installation

Table of Contents

Licenses

Extras

Conclusion

CRUD-DY SQL

SQL(Structured Query Language)

CREATE

READ

UPDATE

DELETE

CONCLUSION

SOURCES

A Collaboration Guide to Github

BRANCH OUT

Pull Requests

Merging 101

Conflict Resolution

A Beginners Guide to HTML

What is HTML?

HTML Structure

Useful Tags

Headings

Paragraphs

Images

Links

Conclusion