DEV Community: Bearded JavaScripter

Set up your next Angular 9 Project for CI/CD on Bitbucket Pipelines

Bearded JavaScripter — Tue, 27 Oct 2020 06:34:50 +0000

Continuous Integration and Continuous Deployment are practices of a good Software Engineering Team and is usually a sign of healthy codebases. It also encourages us to approach Software Development from a TDD standpoint.

Pipelines are a feature of Bitbucket that allow us to run CI/CD when committing/merging into designated branches on the repository. This automates much of what developers were doing before the days of CI/CD.

To learn more about Pipelines, check out this link here.

In this article, I’ll show how to get started on running Pipelines on your next Angular Project. This article assumes that you’ll be using the usual Karma/Jasmine test suite that comes with Angular.

The usual method for a CI/CD Workflow is as follows:

Run unit tests
Run integration tests
Build for Production
Deploy

Here’s the link to the repo and the commit where I made the changes described in this article. Also, you may have to install karma-spec-reporter if it isn’t already installed. Run npm install karma-spec-reporter — save-dev.

Some Background

Pipelines in Bitbucket are triggered by a bitbucket-pipelines.yml file. I’ll get into the configuration of that file in a bit, but for now, it’s important to note that Pipelines run in a Docker environment. While you don’t need to know about Docker, it helps a bunch in understanding what’s happening. The configuration file is also similar to a Dockerfile.

The goal is to run our test using a Headless Browser (preferable Chrome Headless) inside the docker environment. That means:

All our usual testing commands have to be available inside the container
Node has to be in container
Chrome has to be in the container

Let’s start by addressing the first issue.

Setting the Stage

There’s a few things that we need to change in our Karma configuration file as well as our package.json file. You should update your karma.conf.js file to look like the following:

Notice how we added “ChromiumNoSandbox” to our browsers list. In reality, this can be whatever name we want (as long as it’s not the name of another browser). We would have also specified the configuration for ChromiumNoSandbox as using ChromeHeadless browser for testing as well as some flags.

Now we’ll need to edit the scripts portion of our package.json file. This is how it should look:

We’ll run test:local when we want to test locally and test:prod in our bitbucket-pipelines.yml file. Notice how we also changed the npm build command to “ng build — prod”.

Using the “— browsers Chrome” flag on our test:local npm script causes the Chrome UI to be launched. This is fine for testing on our machine locally. However, we won’t be able to do this in our production Pipelines since you won’t have access to a GUI (remember, docker container). Your commands are run in a CLI automatically. This is why we need the Headless Browser for production.

Additionally, by default, karma will always listen for changes so that it can re-run tests. In Bitbucket Pipelines, we don’t want this since we need to move on to additional steps in the pipelines and your build minutes are limited. Listening to changes indefinitely is disabled by using the “ — watch=false” flag on our production test script.

Configuring Bitbucket Pipelines

As I mentioned earlier, there needs to be a bitbucket-pipelines.yml file at the root of our Angular project so that Bitbucket knows to enable Pipelines.

I’ll translate what the above file is saying:

Initialization

Under branches, ‘{master}’ is telling us that Bitbucket will trigger Pipelines when a Commit or Pull Request is made into the master branch. If you want this effect on other branches, then replace master with that branch’s name.

Step

‘step’ tells Bitbucket that this is the first step in the Pipeline. Pipelines can have multiple steps and can even run in parallel to speed up the overall process. Check out more on steps here.

Name

‘name’ is the name of the current step (pretty self-explanatory).

Image

Strap in, this part merits some explanation. If you’re unfamiliar with Docker and containerization in general, then this article provides an amazing insight. But I’ll still try to simplify as much as possible :)

A container is simply an execution environment. This environment needs a base image, which is just some installed software and some commands that are available at command line. So for example, a container that has node image as its base has node, npm and npx installed and available at the command line.

Bitbucket Pipelines run inside a Docker container and you are allowed to specify whatever image you want (as long as it’s available publicly such as on DockerHub).

In the context of the bitbucket-pipelines.yml file, we defined a rastasheep/alpine-node-chromium:12-alpine image. That’s a lot to digest from just the name alone. What it simply means is:

The image was made by rastasheep (a huge shoutout and thank you to him for this Docker image)
Alpine Linux is the base of this image
This image has node 12 and Chromium installed.

This is good news as this gives us Chrome Headless inside our container! It also allows us to run those npm test scripts that we set up earlier since node 12 is installed as well.

Caches

‘cache’ tells Bitbucket to save certain resources instead of having to re-download them all the time. This ultimately saves time on Pipeline execution.

The ‘cache’ field works with multiple languages. In this case, we’re telling Bitbucket to cache our node_modules folder after the pipelines is complete.

Script

‘script’ defines a series of instructions to be run once the pipeline has been set up. Pipeline set up simply involves pulling the specified image and copying the files made on the latest commit that triggered the pipelines into the docker container.

We’ll run “npm install” as the first command to create a node_modules folder inside our docker container.
Then we’ll run “npm run test:prod to allow Karma to run our Jasmine tests in the Headless Browser.
Finally we’ll run “npm run build” to trigger the Angular production build.

Artifacts (optional)

‘artifacts’ allow us to store our artifacts in the pipelines docker container to carry forward into subsequent steps. This is useful for multi-step pipelines or it might precede a series of parallel steps that require the build artifacts (such as integration tests and deployment).

One final point to note is that any error thrown will stop the pipeline and cause it to fail. Make sure that the bitbucket-pipelines.yml file is configured correctly and all your tests are passing!

Enable Pipelines

Now that your changes have been made and your bitbucket-pipelines.yml is at the root of your repository. You now have to manually enable pipelines.

This can be done by clicking “Pipelines” on the left side menu, scrolling to the bottom where you’ll see your .yml file. After a few seconds of Bitbucket checking the .yml file for syntax errors, you should see the “Enable” button turn green. This will trigger a pipeline build and enable pipelines on your repository.

Deployment

At this point, our tests are passing and the production build works. Now all that’s left is to deploy our application. Deployment can happen in a number of ways:

You can use the scp command to deploy to a remote web server (not really recommended)
You can push the build artifacts to another repository.

The second option requires a little more setup which I won’t go into now. But it does involve using an image that also has git installed and setting the password to the account of the repository that houses the build artifacts.

Conclusion

And that’s it! You’ve successfully set up a CI/CD environment for Angular using Bitbucket Pipelines! I’ve only included the basic default tests that come with generated components and services to keep the demo short and simple.

Let me know what you think of this article and I’ll try to improve it as much as I can :)

TDD in Angular - Further HTTP Testing

Bearded JavaScripter — Tue, 06 Oct 2020 03:04:34 +0000

In our last article, we would have tested basic HTTP requests and dictated how the response would look. However, many unexpected things can happen when sending a request. We need to handle these situations so that our application doesn't crash and the User Experience remains flawless.

Code for this article can be found here

Understanding the HttpErrorResponse

Before we test situations where our requests can fail, we need to understand the HttpErrorResponse. This is a class that Angular wraps around any network errors thrown by the browser before it reaches into our application.

Failing HTTP requests are caught by the error callback of the subscribe function and the error parameter is of type HttpErrorResponse. This is useful for UI where we can grab the error message and display it to the user. It is also useful for testing where we expected our request to fail and have a certain status code.




this.http.get('/some/failing/request').subscribe(
   (data) => { console.log(data); },
   (error: HttpErrorResponse) => { /*Access error object here*/ }
);

All responses carrying 400 and 500 status codes are immediately treated as an error and will cause the subscription to fail.

Handling Failed requests

There are a number of ways to handle failed requests and the choice may depend on the application domain and business rules. Generally speaking, we can:

Tell the user something went wrong
Retry the request in the background x number of times
Redirect to another page
Return a default value

It's always a good idea to let the user know what happened so they won't be left waiting and confused. This can take the form of a simple pop up message on the screen. It is easy to replace this code in the future if error handling methods change.

Generally, when subscribing to observables fail, code inside the next and the complete callbacks never run. Therefore, whenever we expect our requests to fail, we need to run our assertions inside the error callback. This is useful for testing if certain error messages are being displayed for different types of errors.

Ideally, we want to simulate a failing request and test that our application recovers. In other words, even though the request may have failed, our application code won't throw an error and freeze up. Let's get started.

Writing our tests

We'll use the same To-Do list service from our previous article.
Let's test our getAllTodos function but if the server fails, we return an empty array.

Remember that our service looks like this:

I made a separate test suite for this function since I wanted to test more than what I described above.

Since our function is supposed to recover from the error and continue normally, our assertions are in the next function of the subscribe. We would expect that the response data is defined, it is an array and it has a length of 0.

We can simulate different statuses, status texts, headers and more by passing in a second parameter into testRequest.flush. In this case, a status of 500 was simulated which means an internal error has occurred in the server.

When we run our test, it fails since we haven't modified our code to take care of this situation.

Notice how the error callback is triggered and fail function that Jasmine provides is executed. However, our tests will pass if we modify our code to the following:



getAllTodos() {
  return this.http.get(this.url).pipe(
    catchError((error: HttpErrorResponse) => {
      if (error.status === 500) {
        return of([]);
      }
    })
  )
}

The above code says to execute the HTTP request but if an error occurs and the response status is 500, then return an Observable containing an empty array. We return an Observable as opposed to the raw value because this is what catchError expects.

Testing unauthorized requests

Usually, when dealing with authorization, we include an access token in our request headers so that the server knows who we are. Absence of this token means that the server should reject the request and return a 401 response.

Let's say that we needed to be authorized to update a to-do item.
We can test that a certain error message is displayed if the request is unauthorized.

Our test would look something like this:

and the corresponding code to make the test pass will be:




updateTodo(updatedItem: Todo) {
  return this.http.put(`${this.url}/${updatedItem.id}`, updatedItem).pipe(
    catchError((error: HttpErrorResponse) => {
      if (error.status === 401) {
        this.displayError(error.statusText);
        return of(null);
      }
    })
  )
}

Testing retries

There are times where the user, through no fault of their own, may have an unstable connection. Though we may display an error message on the screen when a request fails, we should first retry the request in hopes that the response comes through.

Let's say we want to retry getting a single to-do item 3 more times after it fails the first time. If it fails, after 3 retries, then it should throw an error.

Our test:

And the corresponding code:



getSingleTodo(id: number) {
    return this.http.get(`${this.url}/${id}`).pipe(
      retry(3),
      catchError(error => {
        return throwError(`Failed to fetch item with id ${id}`)
      })
    )
  }

In our test, we would have simulated a 404 error but our function actually catches all errors and then retries the request. Additionally, notice that the for loop in our test runs 4 times. This is for the original request and then the following 3 retries.

We also expected this function to throw an error. Therefore, our assertion was in the error callback of the Observable.

Conclusion

In this article, we gained a deeper understanding of the HttpErrorResponse and how it appears in Observables. We also tested Http Requests further by manipulating the response data and status code.

This forms merely the foundation of testing more complex Http Requests that chain main RxJs operators together. Hope you begin writing your requests with more confidence and for a better User Experience. Thanks for reading 😄

TDD in Angular - Basics of HTTP Testing

Bearded JavaScripter — Thu, 01 Oct 2020 00:14:19 +0000

It won't be much of a Web Application if it doesn't make HTTP requests, does it? However, it's easy to forget that these need to be tested as well!

In this article, I'll cover how to unit test HTTP requests in your Angular Application so you can have the confidence that they'll always work as expected.

Code for the article can be found here.

Setting up our code

Let's say that our HTTP calls live in a service that handles to-do items. We can do our basic CRUD operations: getting our to-do items or a single one, creating new items, updating or deleting items.

I'll be using JSONPlaceHolder for this since it's the quickest way to get started. The most barebones CRUD service should look like this:

After importing HttpClientTestingModule, the auto-generated spec file should look like this:

At this point your only test ("it should be created") should be passing.

HTTP Testing Method

Remember that during testing, we're not actually making any requests. We're only concerned with if the request was sent and if a response is handled properly when it returns. Anything that happens in between that is out of the scope of unit testing.

Therefore, let's say that we're unit testing a GET request, we only care that the request is sent and, if the request is successful, some data comes back.

Keep in mind that Angular HttpClient uses Observables rather than promises so we have to adjust our tests accordingly!

Angular provides an entire module to help us test HTTP Requests called the HttpClientTestingModule that allows us to:

Mock a request
Create a fake request with any status code
Pass along a response with fake data
Cancel a request
And much much more!

This means we can test our requests from every angle possible and have our application handle as much cases as possible. I'll cover these in future articles. Let's get set up!

Setting up HTTP Mocks

We need to establish a Mock network that allows us to control when requests are sent, what data is returned and whether or not the request was successful. This comes in the form of HttpTestingController as seen below:

Notice that in the afterEach block, we called httpMock.verify(). This ensures that there are no pending requests in our mock network before moving on to other tests.

Now we can really start testing our code!

Testing Requests

We want to test getSingleTodo. Based on the function name, we can expect that the HTTP response will contain a todo object. Let's represent our expectations as tests.

In the above code, we:

ran our getSingleTodo function and expected the result to be defined
used the controller to expect a request to have the URL https://jsonplaceholder.typicode.com/todos/1
expected the request to be a GET request
used the controller to manually send the request with the fake todo data.

Under normal circumstances, the getSingleTodo function would have made an actual request but our HttpTestingController intercepted the request and returned the fake data using testRequest.flush.

We can now use this information to test POST requests. These contain a request body and can return data along with the status code.

This test ensures a POST request is sent to the correct URL and the created data is returned.

Conclusion

In this article, we learned:

the theory behind testing HTTP requests by using a mock network
setting up the mock network using HttpTestingController
running fake requests and testing their URLs, methods and return values

The next article will show how to control fake requests so we can test our application in the event of unauthorized requests, server crashes and basic error handling.

Hope you enjoyed reading! 😄

Angular Modules - Basics

Bearded JavaScripter — Sun, 13 Sep 2020 05:52:45 +0000

Angular is a popular framework for building rich UIs and high-performance Web Applications. It's also very opinionated in its code structure, meaning that the framework prefers things to be done "the angular way". Part of this means including Angular Modules in your application/library. But what are modules exactly? 🤔🤔🤔

Modules

An Angular Module is simply a way to group individual pieces of logic and components together under one umbrella. Let's take a look at the most common module that all Angular applications have: AppModule.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { AppComponent } from './app.component';

@NgModule({
  imports:      [ BrowserModule ],
  declarations: [ AppComponent ],
  providers: [],
  bootstrap:    [ AppComponent ]
})
export class AppModule { }

There is an @NgModule decorator that tells Angular to prepare this class to be a Module.
The decorator accepts an object that customizes the module.

The bootstrap option is specific to AppModule since it specifies the entry point through which Angular loads the rest of the application.

The declarations array shows what this module contains. Components, pipes and directives are listed here and can be used within this module and can interact with each other. For example, if our AppModule was:

@NgModule({
  imports:      [ BrowserModule ],
  declarations: [ AppComponent, TestOneComponent, TestTwoComponent],
  providers: [],
  bootstrap:    [ AppComponent ]
})
export class AppModule { }

Then inside our app.component.html, we could have something like:

<app-test-one> </app-test-one>
<app-test-two> </app-test-two>

This is because these 2 components were declared in AppModule and therefore, were made available. Generally speaking, whatever we put in the declarations array of AppModule becomes globally available to use.

The imports and exports array tells us what other modules are connected to this one. It allows us to compose modules together like lego blocks. For example:

@NgModule({
  imports:      [ CommonModule ],
  declarations: [ FirstComponent, SecondComponent ],
  providers: [],
  exports: [FirstComponent]
})
export class FirstModule { }

@NgModule({
  imports:      [ CommonModule, FirstModule ],
  declarations: [],
  providers: [],
})
export class SecondModule { }

Usually these modules would be in different files but they are next to each other for the sake of example. We can see that:

FirstModule exports a component called FirstComponent
SecondModule imports FirstModule. This means that FirstComponent is now available to use inside of SecondModule.

We also see that FirstModule has another component called SecondComponent but it isn't exported. This means it can never be made available to other modules that import FirstModule.

The providers array allows us to inject default or replacement values, classes and more wherever it appears in code associated with our module. It's much clearer with an example.

Angular Material Components have many defaults but we can change those defaults using the providers array of the module where our Material Components are imported.

@NgModule({
  imports:      [
    BrowserModule, 
    BrowserAnimationsModule,
    MatExpansionModule
  ],
  declarations: [ AppComponent ],
  providers: [
     { 
      provide: MAT_EXPANSION_PANEL_DEFAULT_OPTIONS,
      useValue: {
        collapsedHeight: '64px',
        expandedHeight: '80px'
      }
    }
  ],
  bootstrap:    [ AppComponent ]
})
export class AppModule { }

In the above example, we tell Angular Material to ignore the defaults set for <mat-expansion-panel> and apply the configuration that we provided. Remember that this will affect all expansion panels used in this module.

Conclusion

We covered what an Angular Module is and the basic parts that make up Angular Modules. Hopefully this article was helpful and that you understand modules just a little more.

There are lots of other topics to cover in Angular Modules and I aim to tackle them all. So stay tuned and thanks for reading! ❤️

Angular Material Handbook: Setup and Basics

Bearded JavaScripter — Sat, 30 May 2020 00:30:13 +0000

If you're an Angular developer, chances are that you've heard of Angular Material. If not, then that's okay, I'm here to guide you.

Angular Material is a component library that follows the Google Material Design Spec. Buttons, tabs, form fields and loading spinners are just a few of the many components in this library and it's super easy to develop applications quickly.

My goal with this series is to walk through each and every single component and show you how to use it, take advantage of its API and customize them for your own applications. We will need to run through a few foundation concepts before hitting the components but I'll try my best to keep it short and sweet. Let's get started!

Note that at the time of writing, I'm currently using Angular 9 with its corresponding Angular Material Version. I'll try my best to update these articles as Angular updates.

Hint: All the code for this article can be found here.

Installation and Setup

Create a new project by running ng new angular-material-tutorial and cd into the root directory of the project. Once inside, we need to run ng add @angular/material.

This will install the necessary npm modules and walks us through some default configuration options. Let's walk through them.

Themes

The first question we need to answer is what theme we would like to pick.



? Choose a prebuilt theme name, or "custom" for a custom theme: (Use arrow keys)
❯ Indigo/Pink        [ Preview: https://material.angular.io?theme=indigo-pink ] 
  Deep Purple/Amber  [ Preview: https://material.angular.io?theme=deeppurple-amber ] 
  Pink/Blue Grey     [ Preview: https://material.angular.io?theme=pink-bluegrey ] 
  Purple/Green       [ Preview: https://material.angular.io?theme=purple-green ] 
  Custom

Pick any that you like, I'll choose Indigo/Pink as my default. We'll look at custom themes in a later article, I promise! But for now, I'll link the previews below.

Indigo/Pink
Deep Purple/Amber
Pink/Blue Grey
Purple/Green

It's important to pick a theme that matches the feel of your application or a theme that matches the brand of your company. But more importantly, we need to keep accessibility in mind. Angular Material Themes should all conform to the WCAG Standards. These rules are laid out so that people who are differently-abled can still access our applications.

One example is maintaining an acceptable level of contrast between background and foreground to ensure visibility of content. This is also part of WCAG Compliance and should be adhered to. Failure to adhere to these rules can actually result in a lawsuit in some parts of the world!

Angular Material Typography



? Choose a prebuilt theme name, or "custom" for a custom theme: Indigo/Pink        [ Preview: https://material.angular.io?theme=indigo-pink ]
? Set up global Angular Material typography styles? (y/N) y

Unless you have your own Typography System, you'll want to select yes for this setting. This gives us access to a lot of classes responsible for spacing, shadows, animations, etc. By default, Angular Material does not apply any global CSS but these will be applied within components and to child elements of a parent bearing the .mat-typography class. You can find out more here.

Browser Animations



 Choose a prebuilt theme name, or "custom" for a custom theme: Indigo/Pink        [ Preview: https://material.angular.io?theme=indigo-pink ]
? Set up global Angular Material typography styles? Yes
? Set up browser animations for Angular Material? (Y/n) y

You'll want to select yes for this one as well as most of Angular Material UX interactions rely on animations. It follows the Material Design Guidelines on Motion.

Finishing Installation



UPDATE src/app/app.module.ts (502 bytes)
UPDATE angular.json (3972 bytes)
UPDATE src/index.html (526 bytes)
UPDATE src/styles.scss (181 bytes)

At this point, the installation is complete and the above files have been altered. Here's a brief summary:

Material Design Icons and the Roboto Font (at font weights 300, 400 and 500) has been added to your index.html. You can add more of these weights if needed. Weights are in multiples of 100 and ranges 100-900. .mat-typography has also been applied to your body.
Default styles have been added to your styles.scss file
The .css theme that we selected earlier has been inserted into angular.json under the styles section of our application build and test configuration
package.json and package-lock.json were updated with the installed packages.

Now we can run ng serve and open our browser on localhost:4200 to see our Angular Application. If you've reached this far without any errors, then you've sucessfully added Angular Material to your project 😄

Templating Basics

Angular gives us access to the properties of an HTML Element by allowing us to create a Template Reference. This reference can now be accessed directly by our HTML just like a component variable or inside the component itself using the @ViewChild decorator.

We won't need to use @ViewChild unless necessary but I wanted to illustrate how to use Template Referencing to our advantage. It's also extremely vital knowledge to have when working with Angular Material.

Let's say we have a counter component. This component starts at 0 and shows the number by default. We have the option to show, hide and increment the number. But we want parent components to control these actions. I used inline styles and template as the component was small.



import { Component } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `
  <h2>My Counter - {{showNumber ? "shown" : "hidden"}}</h2>
  <p *ngIf = 'showNumber'>{{num}}</p>`,
  styles: [':host { text-align: center; }']
})
export class CounterComponent {

  num: number = 0;
  showNumber: boolean = true;

  constructor() { }

  increment() { this.num++; }
  show() { this.showNumber = true; }
  hide() { this.showNumber = false; } 
  private toggle() { this.showNumber = !this.showNumber; }

}

Now let's take a look at our app.component.ts. I also used inline styles and template here since there isn't much code.



import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  template: `
    <h1>Angular-Material-Tutorial</h1>

    <app-counter #counter></app-counter>
    <button (click) = 'counter.increment()'>Add number</button>
    <button (click) = 'counter.show()'>Show Counter</button>
    <button (click) = 'counter.hide()'>Hide Counter</button>
  `,
  styles: [
    `h1 {
      text-align: center;
      padding: 20px;
    }`,
    `button {
      border: 0;
      outline: 0;
      padding: 10px;
      border-radius: 8px;
      display: block;
      margin: 10px auto;
  }`]
})
export class AppComponent {}

Notice how our app component has absolutely no code inside the class. Not even a constructor! Yet, if we click on the Add Number button, it will increment the count, and our Show and Hide Counter buttons will also work as expected.

We managed to access the properties and methods of the CounterComponent through the AppComponent because of Template Referencing.

When we say <app-counter #counter></app-counter>, we are accessing this particular instance of the CounterComponent class. And since the properties and methods boil down to plain JavaScript Objects, we can access them as we do with regular objects (counter.increment() for example). Any property or instance marked as private cannot be accessed through Template Referencing.

This simple, but powerful, feature of Angular allows us to accomplish useful tasks without needed to bloat our TypeScript Class. Additionally, this is the very technique that we will use to access many of the properties of the Angular Material Components in order to take full advantage of them.

Conclusion

In this article, we gained an understanding of what Angular Material is, added Angular Material to our project and learned about Template Referencing and how it relates to Angular Material.

In the next article, we'll get started on simple components from the Buttons and Indicators Section. Thanks a lot for reading! 😄

TDD in Angular - Dependency Injection and Mocking

Bearded JavaScripter — Thu, 28 May 2020 01:36:22 +0000

In our last article here, we went through the basic structure of an Angular Unit Test and went on to test services. In this article, I want to show how to connect your service to a component and how to properly test this from a Test-Driven Development perspective.

Code for this article can be found here

Let's get started!

Creation of an inventory component

Let's say we want to create a component that takes our inventoryCount from the Inventory Service and displays it, as well as increase and decrease the count. This means that InventoryService is a dependency of InventoryComponent. In Angular, we inject dependencies through the constructor.

Therefore, we'll need to inject our InventoryService through the constructor of our InventoryComponent to have access to the methods.

I know there are better ways to update a count in a service and bind it to a component (such as using an Observable). This is just to illustrate a concept.

Whenever we bring in dependencies into components, we should always make sure that those services are tested first so that they behave as expected. Our InventoryService was tested in the previous article so it's safe for us to use it now.

The logic for this component is beyond simple but there's still a key concept of testing that it covers. We don't need to re-test the service code in this component, but we do need to make sure that it is called when needed.

Let's focus on the component test and run through what the auto-generate code means. Remember we can focus on a test suite by using fdescribe (focused describe) and focus on a single test using fit (focused it).

We see that an instance of the component is created and a fixture is set up to house the component instance. This also gives us access to component life cycle methods and a DOM that we can use during our unit tests. You can read more about fixtures here.

TestBed.createComponent(InventoryComponent) instantiates the component, which means that the constructor code is immediately executed along with all the component life cycle hooks implemented by that component. fixture.detectChanges() is responsible for any updates made to the component. It syncs any component variables bound to the DOM. On the first time that it is is run, it runs ngOnChanges() and ngOnInit() (Thanks @LayZeeDK for the correction! ❤️). You can read more about ngOnChanges and ngOnInit on the docs.

If the component has any dependencies, those are instantiated as well, meaning that their constructor functions are immediately executed. This breaks our concept of unit testing since multiple pieces of code are being brought into this one unit test suite. These dependencies need to be mocked.

Mocking Dependencies

Typically when mocking a dependency, a dummy class is provided with many of the same methods as the original. These methods do not provide functionality, but they may just return predictable values that we can use for testing purposes.

For example, you may want to mock network calls, return a known value and see if your components and services behave as they should. You may want to willingly return errors from mock services to see if your application handles errors gracefully. You can even mock Angular features such as the Router.

All this is necessary to isolate the piece of code to be tested. Otherwise, when a test fails we won't know if a dependency or the code in question caused it, which leads to many wasted hours and a poorly designed codebase.

Let's create a MockInventoryService and supply that in place of our InventoryService in the component unit test. We know that the service is already tested, so if any tests fail, the bad code has to be in our component.

Notice how our incrementCount and decrementCount are basically No-ops. Because the logic of this service is so simple, we just want to test if these functions are going to be called in our component. If the methods of the mock service are called in the unit test then it is safe to assume that the actual methods of the real service are called in the component during normal execution.

We need to tell our component unit test to replace the injected InventoryService with the MockInventoryService. This is done in the providers array in the module setup of the component test as follows:

Now, whenever incrementCount is called in the component during the unit test, the method from the mock service will be invoked instead.

Writing our tests

In order for us to tell when a method has been called on a service or not, we need to spy on that method. Jasmine can tell us when a function has been invoked, what the parameters were and what the return value was.
This is useful for us to test our component.

When increment() is called in the component, we expect that incrementCount() is called in the service. Similarly, when decrement() is called in the component, we expect that decrementCount() is called in the service. Let's set up our Jasmine spies and write our tests.

We set up our spies at the very beginning of our test suite and instantiated them after we got a hold of the service from TestBed.inject.

expect(incrementSpy).toHaveBeenCalled() tests whether or not the function being spied upon was called during the test.

Conclusion

In this article, we covered the following:

How to inject dependencies into components
The auto-generated unit test of a component
Producing a mock service
Providing the mock service to the component
Spying on functions inside that service.

Hopefully this article was useful to you. There are lots more to learn about mocking and test strategies in Angular and I aim to cover them all.
Thanks a lot for reading!

My Back-end Adventures - Setting up a local database (Postgres)

Bearded JavaScripter — Sun, 10 May 2020 22:11:08 +0000

One of the things I really wanted to get started with was setting up a local database for my Express servers. While using an in-memory data object inside of Express is fine, I wanted something a little closer to a real project.

So I decided to have a local instance of Postgres running. What better way than to host your database inside of a docker container? It eliminates all the complexity of installing Postgres on your system itself and it's easy to get up and running.

In this article, I'll run through how to set up a local postgres database inside a docker container and connect your Express back end to it using Sequelize. Let's go!

TL;DR: All the code can be found here.

Setting up Docker

First thing you'll wanna do is to install docker on your system as well as docker-compose. Docker is a runtime that allows us to run software inside of containers regardless of operating system. That means no frustrating installs and no OS-specific instructions. It works for all! 😄

Once Docker and docker-compose is on your system and ready to go, you'll need to create a docker-compose.yml file. This is a config file for docker-compose that can spin up multiple containers and lets them communicate. Copy and paste the following code into the docker-compose.yml:

The config file does a couple things for us:

Creates 2 services (containers) for us called postgres and pgadmin
Sets the default username and password for us to access externally
Maps the corresponding ports. 5432:5432 on the postgres container means that port 5432 on the host machine is mapped to 5432 inside the docker container. The same logic applies for 5050:80 for pgadmin
Creates volumes for our containers. Even if our container is shut down, our data will persist. postgres:/data/postgres means the postgres folder in our local machine is mapped to the /data/postgres folder inside the docker container
Creates a common network called postgres so that our 2 containers can communicate with each other.

Running the Docker containers and connecting PgAdmin to Postgres

Run docker-compose up in your terminal. Your computer will download the specified versions of the containers before activating them.

Your console output should look something like the following. I'm running an ubuntu system but it should pretty much be the same thing

Once this is up and running, go to localhost:5050 in your browser and you should be greeting with the PgAdmin login screen. This is the administrative interface for Postgres. While this is not necessary to have, it's still pretty cool.

Log using the PGADMIN_DEFAULT_EMAIL and the PGADMIN_DEFAULT_PASSWORD from the docker-compose.yml file. In my example, these are pgadmin4@pgadmin.com and admin respectively.

Let's just recap what we did so far. We created 2 docker containers, one for Postgres and one for PgAdmin. We then launched those 2 containers and connected to PgAdmin through localhost:5050 in the browser. Now we're going to connect PgAdmin to the Postgres container.

Create a new server by navigating to the right and right-clicking Servers > Create > Server.

Give your server a name. I'll call mine express-postgres-docker. Then, navigate to the Connection tab. Fill out the details so it looks like the following:

Let's run through what's happening:

Host name/address is postgres. This field is asking us for the name or IP address of the machine that the Postgres database is located. Since we're using Docker, the container is considered a machine of its own with a name and address. The name is postgres as specified by our docker-compose.yml file. If we were connecting to a locally installed version of Postgres without Docker, it would have been localhost since the database would be located on your local machine.
Port is 5432. This is the standard Postgres port. Since both Docker container are using the same network, they can see each other's port withouth having to use different IP addresses
Maintenance Database is postgres. This is standard and should not be altered.
Username is postgres. This was specified as POSTGRES_USER in the docker-compose.yml file. If you changed it, then you need to specify that change in this field.
Password is password. This was specified as POSTGRES_PASSWORD in the docker-compose.yml file. If you changed it, then you need to specify that change in this field.

Once you hit save, PgAdmin should be connected to your Postgres container.

Setting up your Express server

We'll need to install a few packages to get started. Our dependencies are going to be:

express
pg
pg-hstore
sequelize

Once installed, you'll need to create an app.js that looks like the following:

Run node app.js in your terminal and you should get the following output if your connection was successful:

Listening on port 5000
Executing (default): SELECT 1+1 AS result
Database connected!

Conclusion

Congratulations! You just set up Postgres and PgAdmin in Docker containers and connected it to an Express Sequelize Project. Now you can use this to actually store data for your projects or use it as a platform to start learning more about Database and Database Caching. Happy Coding! 😄

My Back-end Adventures - Intro

Bearded JavaScripter — Sat, 09 May 2020 19:05:31 +0000

TL;DR: This series is about my journey into the world of Back-end Development. Every milestone, small accomplishment, frustration and major achievement is going to be documented in this series. I'll include a few tutorial articles to run through set ups that I found challenging to understand so that others after me can have an easier time. Enjoy! 😄

Just until recently (at the time of publishing this article), I decided to dive into the world of Back end Web Development. I already had a lot of experience on the front end and a deep understanding of Angular. But I wanted to change my Web Development focus slightly as well as my career.

There were a lot of choices laid out in front of me such as:

Python Flask
Node.js/Express
Golang
PHP
Elixir (This one is pretty cool!)

Eventually I settled on Node.js/Express since I was already familiar with JavaScript and already had done one or two really small Express projects on my own. Plus I really like JavaScript modern syntax.

The #100DaysOfCode challenge seemed like a really good way to get me going. I've always had problems with motivation and keeping the discipline to stick with a habit so it was a good fit.

I laid out a bunch of topics to cover and projects along the way so that I don't get stuck in tutorial hell. Here are some of those topics:

Beginner
- Node.js Express basics
- Routing
- MiddleWare
- View/Templating Engines
- SQL ORM (Sequelize)
- NoSQL ORM (Mongoose)
Intermediate
- Security, Passwords and OAuth
- Caching
- State Management
- More Database management
Advanced
- Node.js Core Modules
- Web Sockets
- NginX

There are probably some more that I missed but I'll get to them along the way. So far I've only covered some of the basics but I learned so much that I'm excited to keep going. Can't wait to see what else I learn!

TDD in Angular - Understanding an Angular Unit Test

Bearded JavaScripter — Tue, 21 Apr 2020 22:23:39 +0000

In my previous post, I talked about the Basics of General Testing. It was a short introduction into the different types of testing and how to approach testing in Jasmine.

In this article, I want to take a look at the auto-generated unit test files of an Angular Application and explain what's happening. I'll unit test services for my examples since it's a good place to start understanding the fundamentals. Also, Angular Components have a bit more going on under the hood and that requires an article of its own.

Many Angular developers get confused and even overwhelmed by what's happening in a .spec.ts file. This article will change that.

Code for this article can be found here.

Angular Services

Services are by far the easiest to unit test. They're simply Injectable classes that may or may not have some state and contain a collection of functions. However, they shouldn't be taken lightly. Your services are where all your business logic should be. Therefore, testing them as much as you can will prove useful.

Let's take a look at an InventoryService and its auto-generated .spec.ts file:

There's a few points to note here.

There's a describe block that groups all our tests together for this service. A variable called service is also initialized.

The beforeEach block contains code that is run before every single unit test in this spec file. It helps us have a clean slate before running each test so that previous tests don't interfere. This helps with the essence of unit testing (testing one thing in isolation without any external factors).
There are other blocks of code like this to help us maintain clean tests, namely beforeAll, afterEach and afterAll. You can read more about them and more pretty cool testing tools in the Jasmine Global API.

Looking inside the beforeEach block, we see 2 unfamiliar pieces of code. TestBed.configureTestingModule creates a dummy module for us to work with. TestBed.inject initializes our service and injects it into that dummy module. This holds true for components, pipes, guards, etc. This is the unit testing philosophy combined with Angular's architecture.

An Angular application must have at least one module so a dummy module is created with only the piece of code being tested (in this case, the service) and nothing else. This way, nothing else from the outside can interfere with the tests. Pure Isolation.

Each it block of code is a unit test. it is a function that accepts 2 arguments: A string describing the test and a function that must contain an expect assertion function. This expect function is what Jasmine runs to assert expected values against actual results.

it('should be created'), () => {...} is a unit test that is always created for any component, pipe, service, etc. It doesn't make sense looking at other unit tests if we can't initialize our code in the first place.

Building our Service

Let's say that I wanted to add some code to track the number of items in my inventory and a way to increment and decrement the amount.

Remember! We're approaching this from a TDD standpoint. We can write empty placeholders and then Tests first!

We write tests for what we want our code to do and then consider other cases. Tests for main functionality should look something like this:

You'll notice I used fdescribe as opposed to describe. This means "Focused Describe" and Jasmine will only run this suite of tests instead of all tests in the Application.

When we run our unit tests, we'll notice some failures (as expected).

It's telling us that the "should increment the count" and "should decrement the count" tests are failing. This is expected since we didn't write any code in there as yet. Let's change that.

And now our tests are passing:

The more astute among you might have realized that our decrement function isn't finished. We shouldn't be able to decrement if the inventoryCount is already 0.

A reasonable test for this can be:



it('should not decrement when count is 0', () => {
    expect(service.inventoryCount).toBe(0);
    service.decrementCount();
    expect(service.inventoryCount).toBe(0);
  });

Re-running the tests gives us:

Our function currently decrements whatever value is stored in the service. We want it to decrement only when the value isn't 0. This is also a simple way to make sure that inventoryCount never falls below 0 (assuming you want your system like that).

We can modify the function to be:



 decrementCount() {
    if (this.inventoryCount === 0) return;

    this.inventoryCount--;
  }

Now our tests are passing again.

Conclusion

In this article, we covered the following:

The basic structure of an Angular Unit Test
What happens in the beforeEach block
Why a dummy module is necessary for testing
Building an Angular Service using TDD

There are a lot more of these articles to come where we'll dive deeper into services, mocking, component life cycles, etc. Stay tuned for more and thanks a bunch for reading! 😄

TDD in Angular - The Basics of General Testing

Bearded JavaScripter — Sun, 19 Apr 2020 00:32:02 +0000

You've all hear the crowd harping about how great testing is. But has anyone ever told you what testing is? Or what it means? Or how to even approach testing?

Don't worry, young padawan. I'll guide you through the basics of testing, the different types of testing and how to code in a Test-Driven Development style in Angular.

Hint: You can find all the completed code for this article here.

Why bother to test?

Consider this: If you're a car manufacturer, are you going to sell cars when you don't know whether or not it works? If you're a good car dealer then of course you'll make sure that it works in all the expected conditions. Why is software any different?

Testing gives developers the confidence that our code will work 100% of the time as expected in the expected conditions. If not, then at least our code can fail gracefully (more on that later). Here's a really nice (but slightly long) video on how TDD relates to good code and professionalism.

Types of Tests

Regression Testing

You've actually unconsciously done this type of testing in all the code that you've written! Regression testing formally refers to checking if changes to one part of the code has affected any other parts.

We might unprofessionally know this as making a change, seeing something else break and following the breadcrumbs of broken code until everything works.

Unit Testing

This type of testing will make up at least 65% of your test suite. It's focused on testing individual components. When I say "components" here, I don't mean Angular or React components, I'm just referring to single, small, individual pieces of logic.

That doesn't mean we're going to test each and every function but we test those pieces of code that are most important (which are usually those focused around business logic).

So for example, in an Inventory Management System, we'll want a test to ensure discounts are applied to certain items.

Integration Testing

We know our individual components work individually, but we also need to make sure they don't break when we put them together. This is what Integration Tests are for.

In our Inventory Management System, we'll want tests to make sure that a restocking order is places when inventory on a certain item falls below a certain amount. These tests may combine Inventory Counts and an Ordering System.

End-to-End (e2e) Testing

The applications we write usually have a start point (for example, a login) and an endpoint (for example, a purchase). Testing our apps from start to finish (or from end to end) is critical as this is as close to real-world usage as automated testing can get.

You'll want to take more customer-driven scenarios into these tests such as navigation within the app to ensure the user is still authenticated or if animations and error messages pop up after certain actions.

There are probably more types of tests but these mentioned are the most common.

How to prepare yourself for Test-Driven Development

Test-Driven Development simply means to write our tests before we write our code. Since most of us haven't grown up with TDD in mind, it sounds pretty absurd. Why write the tests first when there's no code to start with?

The reason is that it keeps us very focused on what the code is supposed to do and nothing more. In a way, we subconsciously do this when we write our code, but we don't put down our thoughts into tests.

We usually start off with what the code is supposed to do in our heads, write the code in our IDE and then assume it works. Writing out tests gets those initial thoughts out of our heads and into a form that's more concrete.

Let's do a simple example. We want to write a function that accepts an object, capitalizes the value in the "name" key and returns a new object.

You can fork this StackBlitz repo and code along.

We'll write an empty function first and then write our tests.

We know what we want our code to do, so let's write the corresponding test. If you're using Jasmine, the first unit test should look something like this. Remember, we have an empty function so the first test should fail.

And the resulting failing test:

We expect that the actualResult should be the same as the expectedResult. This is the basis of all tests. As long as our expectations match what is actually produced, then our tests will pass.

Now we can modify the code so that the test passes.

We've just done TDD! We thought about what the code needed to do, wrote the test first and then wrote the code to make the test pass.

Handling more test cases

Our code above works fine but it assumes that the object:

is defined
has a key called "name"
has a defined value in the key called "name"
has a string value in the key called "name"

When writing functions, you may not know where your arguments may come from (perhaps from sources that you cannot easily control such as form data or from an HTTP request). You have to be prepared for a number of cases like those described above so that it is robust. The more assumptions you make, the more room for error that you leave in your code.

Let's throw in some more test cases and see what happens:

Our tests are failing again so we know the areas that we need to work on.
I've decided to include a name key with an empty string if the name isn't available. I've also decided to throw an error if the name key in the object is not a string or if the object is falsy. Let's modify the code so that it works in those cases.

And now all our tests are passing:

Final Words

Test-Driven Development allows us to write simple, yet robust code. It teaches us to consider many cases upfront as opposed to just the way the code is supposed to work. This way, the code isn't prone to breaking at all, or at least as often.

Tests also act as a good form of documentation. Running the tests on a codebase and seeing all the test cases gives us a pretty good indication of what the code is supposed to do.

Unit test descriptions tell us what each piece of logic is supposed to do. Integration tests tell us how pieces are supposed to connect together. End-to-end tests tell us what to expect when using the entire system.

Use Pipes in your next Angular Application! (Part 4)

Bearded JavaScripter — Thu, 09 Apr 2020 14:03:50 +0000

Pipes are a really simple way to transform how data is displayed to the user. Angular comes with lots of built-in pipes for common scenarios (JsonPipe, CurrencyPipe, DatePipe, etc). But what if you need something custom for your project?

In this article, we'll be exploring how to create your own pipes. I'll run through a simple example that adds the correct order suffix to a number (eg. 1st, 12th, -123rd, etc). Let's dive in!

(All code here)

Creating your own Pipes

The first thing you'll need to do is to come up with a suitable name for your pipe. It should reflect what the pipe does. In my case, I'll call the pipe OrderSuffix. Then, run the following command in your terminal.

ng generate pipe OrderSuffix

This will add your pipe to your declarations array in AppModule. The generated code should look like this:

The transform function is responsible for taking the input from the HTML template and producing the output to be displayed.

We want to be able to add an order suffix based on the number, which is mostly determined by the last digit (least significant digit). So 1 becomes 1st, 2 becomes 2nd, 4 becomes 4th and so forth. It's also helpful to note that we're taking in a number and returning a string.

This pipe looks pretty good so far. We defined a suffix map for digits ending in 1, 2 and 3, converting them to 1st, 2nd and 3rd respectively. If the last digit is none of these 3, then we assume the suffix is "th" (4th, for example).

We can demo our pipe inside a simple component as follows:

The component displays the array of numbers with their order suffixes. However, if we look at the very last number, there's a problem.

1st
2nd
3rd
14th
-128th
11st

We need to convert 11 to 11th, not to 11st. Our current pipe will also convert 12 to 12nd and 13 to 13rd, which aren't correct. Remember that the pipe has to work with larger numbers as well, so for example, 1259239411 should still give 1259239411th.

Notice how this problem only occurs for 11, 12 and 13 or numbers that end with 11, 12 and 13. We should deal with those cases first before our general code runs.

Now, our pipe looks for the last 2 digits being 11, 12 or 13 and returns the number with the suffix "th" for all of them. If not, then we run our previous code. Now our output looks a little more accurate.

1st
2nd
3rd
14th
-128th
11th

Lessen your burden:

If you're writing a custom parsing function just to change how data is displayed, then you're better off putting that parsing function inside a pipe.

Without using pipes, inside your component would follow this process:

Define/Import your parsing function
Get the data you want to transform
Run the data through the function and store the result in a new variable
Display that new variable

Whereas with Pipes, we just:

Define the parsing function inside the pipe
Use the pipe in the component HTML template.

No extra imports, no extra variables, and the component is as dumb as possible.

Conclusion

Now you know how to create your own pipes!

This is also the end to my 4 part series on Pipes in Angular. There are 2 built-in pipes that I haven't mentioned (I18nPluralPipe and I18nSelectPipe). Now you know enough to explore these pipes on your own and create some of your own!

Good luck in your Angular journey! 😄

Use Pipes in your next Angular Application! (Part 3)

Bearded JavaScripter — Fri, 03 Apr 2020 13:33:38 +0000

The main use of Pipes in Angular is to transform how data is displayed. Dates, currency and JSON objects are just some of the structures that Angular Pipes can work with.

Check out my first and second articles on Pipes where we cover some of the simpler pipes.

In this article, we'll be moving on to 2 very useful pipes:

DatePipe

This is used for displaying JavaScript Date Objects in a readable format. Angular provides many ways for us to configure the DatePipe, from full or abbreviated day names, from the hours down to the seconds and, of course, varying locales as well (en-US locale is used by default).

And the corresponding output:

Date without Pipe: Fri Apr 03 2020 08:43:22 GMT-0400 (Venezuela Time)
Date with Pipe: Apr 3, 2020

Showing Dates:
Short Date: 4/3/20
Medium Date: Apr 3, 2020
Long Date: April 3, 2020

Date Formatting with Parameters:
dd/mm/yyyy: 3 Apr 2020
yyyy/mm/dd: 2020 Apr 3

Formatting Times
Short time: 8:43 AM
Medium time: 8:43:22 AM
Long time: 8:43:22 AM GMT-4

There's loads more examples on the DatePipe Documentation. Pre-defined formatting options as well as custom formats.

AsyncPipe

Asynchronous Programming is at the very heart of JavaScript. With Angular being built on RxJS and using Observables for HTTP requests, more and more developers end up writing the same code just to extract their data from HTTP Async responses.

With the AsyncPipe, it can dramatically reduce the above code to the following:

The HTML from the second example is important.

Line 8 says: "Subscribe to the character observable and store the response data in char. If char is defined, then show the <p> tag. Else, show the #loading template."

This allows us to set a variable to store the response data straight from the HTML as opposed to declaring it in our Component TypeScript.

Additionally, notice how in the second example, we didn't need to call subscribe. This is because AsyncPipe automatically subscribes for you. Generally speaking, we don't need to unsubscribe from HTTP Observables since Angular auto-unsubscribes for us.

But in general, AsyncPipe automatically unsubscribes Observables on Component Destruction. That's a lot less for us for think about and a lot less for us to code. Always leverage the framework as much as possible.

Note that the same works for promises as well :)

Conclusion

This article was a short, but powerful, introduction to using DatePipe and AsyncPipe in Angular. DatePipe is used to display dates and can show various formats. AsyncPipe extracts the value from an asynchronous data structure and gives us access to it straight from the HTML.

Thanks a bunch for reading! Stay tuned for the next Article where I talk about making your own pipes 😄