Become a cloud pro with hands-on experience in developing, styling, and managing a Cloud-Native web application using Tailwind, Google Cloud, and Firebase. No setup, no cleanup, no hassle.

Cloud Native Web Development - A Hands-On Guidebook-01.jpg

cloud-native-web-app.tar.gz

username

email

access_token

repository_name

author

firebase_proj_name

FIREBASE_TOKEN

cypress_key

cypress_projectID

dev_api_key

sapper

add-firebase-sdk

install-firebase-cli

cypress-cli

headless-mode

headless-mode-2

component-tests-1

component-tests-2

testing-library

cypress-dashboard

enable-tests-CI

enable-PR

svelte-intro

tailwindcss-component

tailwindcss-svelte

tailwindcss-svelte2

user-auth1

login-page

admin-page

user-svelte-store

signin-vs-signout

secure-admin-page

redirect

configure-firestore

create-user-interface-1

write-data-1

persist-new-blog-1

read-data-1

security-rules

configure-emulator

test-fcf-locally

new-service-placeholder

dev-integration

test-new-service

markdown2html

write-test-for-service-1

deploy-service-req-one

deploy-service-req-two

speed-up-CI-CD

local-dev

emulator-start

ch-2/lesson-5

ch-3/lesson-3

ch-1/lesson-4

ch-3/lesson-4

ch-3/lesson-5

ch-3/lesson-6

ch-4/lesson-3

ch-4/lesson-4

ch-5/lesson-1/1

ch-5/lesson-1

ch-6/lesson-2

ch-6/lesson-3

ch-8/lesson-3

ch-8/lesson-4

ch-8/lesson-6

ch-8/lesson-7

ch-8/lesson-8

ch-9/lesson-3

ch-9/lesson-4

ch-9/lesson-5

ch-10/lesson-1

ch-10/lesson-2

ch-10/lesson-3

ch-10/lesson-4

ch-10/lesson-5

ch-11/lesson-2

ch-11/lesson-3

ch-11/lesson-4

ch-11/lesson-5

ch-11/lesson-6

ch-11/lesson-7

create-user-interface-2

create-user-interface-3

create-user-interface-4

write-data-2

write-data-3

persist-new-blog-2

read-data-2

read-data-3

ch-12/lesson-2

ch-12/lesson-3

ch-13/lesson-2

ch-13/lesson-3

ch-13/lesson-4

ch-13/lesson-5

ch-13/lesson-6

ch-13/lesson-7

ch-13/lesson-8

ch-13/lesson-9

new-service-placeholder-copy

write-test-for-service-2

write-test-for-service-3

ch-14/lesson-1

This course is a hands-on guidebook to walk you through the journey to creating your first web application in the cloud.

In this course, you will have hands-on experience in developing, styling, hosting, testing, and efficiently managing a complete Cloud-Native web application. Along with this, you will learn how to make the important decision of choosing a technology or tool for your web application.

By the end of this course, you will have a set of expertise in developing cloud native web applications that will help you throughout your career.

Cloud Native Development with Tailwind, Google Cloud and Firebase

# Testing library

The philosophy behind [Testing Library](https://testing-library.com) is:

**<div style=" text-align: center;">The more your tests resemble the way your software is used, the more confidence they can give you.</div>**

This maps closely with the test pyramid we discussed earlier. Now, we can combine end-to-end tests with a testing library that closely resembles the way our software is used.

# Testing library features

A very important aspect of the Testing Library is to provide the functionality to test whether our HTML is accessible. Besides the DOM tree, there is also an accessibility
tree used by screen readers. To truly develop web applications that are accessible
to anyone, it is important to take accessibility seriously. Please see Mozilla's ["What is accessibility?"](https://developer.mozilla.org/en-US/docs/Learn/Accessibility/What_is_accessibility).

For our convenience, there is a [cypress-testing-library](https://github.com/testing-library/cypress-testing-library) project. We will use that to bridge the gap between Cypress and the Testing Library.

If you are interested in a [Testing Framework Svelte integration](https://github.com/testing-library/svelte-testing-library) to test individual Svelte components rather than using the Cypress framework, you are in luck as well.

Another interesting project is the [Testing Library playground](https://testing-playground.com). At the top, you can create your HTML and see it rendered to the right. Below, you can use the Testing Library to query elements and see details about the queried elements on the side.

# Alternatives

This is a tricky one to list alternatives for. On the one hand, the Testing Library is an
optional tool included in this course because of its added benefit to writing tests in the way users interact with the web application. On the other hand, it is important to highlight its accessibility capabilities. An alternative solution is unknown at this time.

# Why use testing library?

To illustrate why we use the Testing Library, let's look at a Cypress test to
validate functionality related to a dialog. Here is the HTML we will write a test case
for:

```HTML
<body>
  
  <main aria-hidden="true"> 
    <button>Open dialog</button>
  </main>
  <div role="dialog">
    <button>Close dialog</button>
  </div>
</body>
```

This HTML snippet shows three elements of interest:
* A button to open a dialog
* A div that represents a dialog
* A button to close the dialog, located within the dialog div

Is the dialog open or closed right now? Well, that depends. Visually, we don't know, because we would need to look at the CSS. From an accessibility standpoint, the dialog is open and the "Open dialog" button (and the parent `<main>` element) are
hidden.

You may want to write a Cypress test similar to the following:

```
it("has open dialog button", () => {
  cy.contains("button", "Open dialog");
});
```

That test passes, but should it? Let's look at a test written with the Testing Library:

```
it("has open dialog button - Testing Library", () => {
 cy.findByRole("button").should("have.value","Open dialog");
});
```

That test fails! It fails because the "Open dialog" button is a child of an element with
an `aria-hidden="true"` attribute. To accommodate users with a screen reader, the failing test is what we want, whereas the Cypress test lets us believe everything is okay, when in fact it is not.

Remember, the more your tests resemble the way your software is used, the more
confidence they can give you.

# Testing library

The philosophy behind [Testing Library](https://testing-library.com) is:

**<div>The more your tests resemble the way your software is used, the more confidence they can give you.</div>**

This maps closely with the test pyramid we discussed earlier. Now, we can combine end-to-end tests with a testing library that closely resembles the way our software is used.

# Testing library features

A very important aspect of the Testing Library is to provide the functionality to test whether our HTML is accessible. Besides the DOM tree, there is also an accessibility
tree used by screen readers. To truly develop web applications that are accessible
to anyone, it is important to take accessibility seriously. Please see Mozilla's ["What is accessibility?"](https://developer.mozilla.org/en-US/docs/Learn/Accessibility/What_is_accessibility).

For our convenience, there is a [cypress-testing-library](https://github.com/testing-library/cypress-testing-library) project. We will use that to bridge the gap between Cypress and the Testing Library.

If you are interested in a [Testing Framework Svelte integration](https://github.com/testing-library/svelte-testing-library) to test individual Svelte components rather than using the Cypress framework, you are in luck as well.

Another interesting project is the [Testing Library playground](https://testing-playground.com). At the top, you can create your HTML and see it rendered to the right. Below, you can use the Testing Library to query elements and see details about the queried elements on the side.

# Alternatives

This is a tricky one to list alternatives for. On the one hand, the Testing Library is an
optional tool included in this course because of its added benefit to writing tests in the way users interact with the web application. On the other hand, it is important to highlight its accessibility capabilities. An alternative solution is unknown at this time.

# Why use testing library?

To illustrate why we use the Testing Library, let's look at a Cypress test to
validate functionality related to a dialog. Here is the HTML we will write a test case
for:

```HTML
<body>
  
  <main aria-hidden="true"> 
    <button>Open dialog</button>
  </main>
  <div role="dialog">
    <button>Close dialog</button>
  </div>
</body>
```

This HTML snippet shows three elements of interest:
* A button to open a dialog
* A div that represents a dialog
* A button to close the dialog, located within the dialog div

Is the dialog open or closed right now? Well, that depends. Visually, we don't know, because we would need to look at the CSS. From an accessibility standpoint, the dialog is open and the "Open dialog" button (and the parent `<main>` element) are
hidden.

You may want to write a Cypress test similar to the following:

```
it("has open dialog button", () => {
  cy.contains("button", "Open dialog");
});
```

That test passes, but should it? Let's look at a test written with the Testing Library:

```
it("has open dialog button - Testing Library", () => {
 cy.findByRole("button").should("have.value","Open dialog");
});
```

That test fails! It fails because the "Open dialog" button is a child of an element with
an `aria-hidden="true"` attribute. To accommodate users with a screen reader, the failing test is what we want, whereas the Cypress test lets us believe everything is okay, when in fact it is not.

Remember, the more your tests resemble the way your software is used, the more
confidence they can give you.

Get an introduction to the Testing Library.

Introduction to Testing Library

Introduction

Create a GitHub Project Using Monorepo Template

Set Up Backend Using Sapper Template

Host Your Web App on Firebase

Set Up The Continuous Deployment Pipeline

Local Development

Feature Toggles

Production Monitoring & Rollbacks

Testing

Tailwind CSS

User Authentication

Database - Cloud Firestore

Firebase Local Emulator Suite

Trigger Services Based on Events

Final Tasks

What's Next?

Introduction to Testing Library

Testing library