Gain insights into building real-world components using JavaScript. Delve into dropdown menus, auto-validating forms, autocomplete search, infinite scroll, and tooltips to tackle common frontend challenges seamlessly.

Learn to apply your introductory knowledge of HTML, CSS, and JavaScript to build beautiful, real-world components. In this course, you'll go through the process of developing several complex components, including:

- eBay's dropdown menu
- Gmail's auto-validating form
- Google's main autocomplete enabled search
- Twitter's infinitely scrolling list
- Medium's tooltips

You'll learn how to approach common frontend challenges, what questions to ask yourself, how to design solutions once you've thought of them, how to debug and work with mistakes, and more.

The end-goal is to empower you to look at anything you see on a website and be able to say, "I can build that!"

Intermediate JavaScript: Building Frontend Components

## Types of tests
There are three broad categories of tests that can be automated in web apps.

1. **Unit tests**
  - These test individual functions. For example, if you have a function that's supposed to return true given a certain input and false otherwise, that's easily testable with unit tests.
  - It only covers JavaScript code
2. **Integration tests**
  - These test functions that are working together. For example, when one function calls another and uses that result in a different function call.
  - It only covers JavaScript code. A lot of business logic can be tested here.
3. **Acceptance Tests**
  - These test functionality in the web app as a whole through the client interface. For example, when the user clicks on a button, a popup appears.
  - A lot of the user experience guarantees are tested here. JavaScript should not be called directly; these tests are concerned with the outcome of user-taken actions.

People have different interpretations of how tests should be split, an​d there's no standard approach here. It doesn't matter, though. Labels on tests aren't as important as simply having tests that cover the critical parts of your app. You also shouldn't write tests for the sake of writing tests. Having 100% code coverage (mean​ing you have tests that hit every line of code) is a mostly meaningless goal. I'd much rather have a concentrated set of tests on the parts that are prone to bugs than an equal distribution of tests that cover 100% of my code.

So let's try some test-driven development! This just means we write the tests before we have the code to make them pass.

In a real application, you'll want to use a testing framework. These make it much more pleasant to write and run your tests. There are many to choose from for each category of tests, but the differences are mostly syntactical. Writing the actual tests is easy in any framework or library. **The hard part is choosing what to test and how to test it.**

# Types of tests
There are three broad categories of tests that can be automated in web apps.

1. **Unit tests**
  - These test individual functions. For example, if you have a function that's supposed to return true given a certain input and false otherwise, that's easily testable with unit tests.
  - It only covers JavaScript code
2. **Integration tests**
  - These test functions that are working together. For example, when one function calls another and uses that result in a different function call.
  - It only covers JavaScript code. A lot of business logic can be tested here.
3. **Acceptance Tests**
  - These test functionality in the web app as a whole through the client interface. For example, when the user clicks on a button, a popup appears.
  - A lot of the user experience guarantees are tested here. JavaScript should not be called directly; these tests are concerned with the outcome of user-taken actions.

People have different interpretations of how tests should be split, an​d there's no standard approach here. It doesn't matter, though. Labels on tests aren't as important as simply having tests that cover the critical parts of your app. You also shouldn't write tests for the sake of writing tests. Having 100% code coverage (mean​ing you have tests that hit every line of code) is a mostly meaningless goal. I'd much rather have a concentrated set of tests on the parts that are prone to bugs than an equal distribution of tests that cover 100% of my code.

So let's try some test-driven development! This just means we write the tests before we have the code to make them pass.

In a real application, you'll want to use a testing framework. These make it much more pleasant to write and run your tests. There are many to choose from for each category of tests, but the differences are mostly syntactical. Writing the actual tests is easy in any framework or library. **The hard part is choosing what to test and how to test it.**

In this lesson, we'll learn what Test Driven Development (TDD) is, the three categories of tests involved, what Unit Tests are and how to build and run them.

Welcome

Building a Dropdown Menu

Building the Autocomplete Search

Building Tooltips

Building an Autovalidating Form

Building an Infinite List

From Toy Components to Production

Test Driven Development

Types of tests #