Skip to content

Latest commit

 

History

History
74 lines (43 loc) · 5.1 KB

1.md

File metadata and controls

74 lines (43 loc) · 5.1 KB

Lesson 1 - A real-world example

When we're starting on a software project, most of the time, some (or a lot of) code already exists, and it's not everyone that has the privilege of working on green-field projects, in other words, those starting from scratch.

I've structured this course bringing real-life situations of software projects, but on a smaller scale, so that we can focus on learning different concepts and techniques, where you'll work on an existing codebase, with some tests already written (not as good as they could've been), and with scenarios to be covered.

The application under test is called Hacker Stories. It was developed based on the exercises of The Road to React book, written by Robin Wieruch, which is a book that I highly recommend for anyone who wants to learn or improve their skills with React.

The application was written in TypeScript, using React in the frontend and the public API of Hacker News as the backend. The app is hosted on Firebase.

Note: Although I wrote the application in TypeScript, this course's tests were (and will continue to be) written in JavaScript to make your life easier.

Attention: do not run any performance testing against the course's application. It was not developed for this purpose.

Application's functionalities

The main feature of the Hacker Stories app is to allow searching via the Hacker News API and list the results (20 for every "page"), with title, author, number of comments, and points.

When visited for the first time, by default, it searches by the term 'React'. This way, we can ensure it's correctly integrated with the API since the beginning.

Besides that, the last searched term is stored in the browser's localStorage so that it can be available in the search field even after a page refresh.

For every story, there's a button to remove it from the list.

Also, it's possible to order the results (ascending and descending) by title, author, number of comments, and points.

After listing the first 20 stories, you can click on the More button to search for the next 20 stories (something like pagination.)

There's also the functionality of the last searched terms, where a max of 5 buttons are visible right below the search field, with the text of the last searched terms, for quick search.

Finally, in case of an error, a fallback component is rendered with the "Something went wrong ..." message.

Note: In this version of the application, there's no cache of the results, which means every search makes a new request to the API.

The existing tests

The Hacker Stories application already has end-to-end tests. They're:

  • Test that ensures the footer is visible. This test exists since the button to remove a story uses an icon from Freepick, and I've to cite them somewhere to give them the credits
  • Test that ensures 20 stories are rendered and then the next 20 after clicking the More button
  • Test to ensures that the user can remove a story from the list
  • Test that searches for a term by typing and pressing Return
  • Test that searches for a term by typing and clicking the Submit button
  • Test for quick search using a last searched term
  • Test that ensures a max of 5 buttons are shown for the last searched terms

The pending tests

Besides the already implemented tests, there are some still to be written to ensure higher code coverage. They are:

  • Test that ensures the correct data is rendered for every row in the list
  • Tests for ordering by title, author, number of comments, and points
  • Tests for situations of server or network failures

Issues with the existing and pending tests

Despite part of the code is already covered by tests and we're planning to increase this coverage, the existing approach suffers from some problems. They're:

  • All scenarios depend on the real Hacker News API, which means that if it's out, all tests (except the one for the footer) will fail
  • Since the API is external, we can't control what is returned to the frontend, making it difficult to implement some tests (e.g., the pending tests for the order by feature) or making them more complicated than they need to be
  • Testing error situation is not trivial when talking about end-to-end tests

Your misson

During the course, I'll show you specific problems (one at a time), some options to solve them (some better than others), and exercises for you to solve such problems. While solving the problems, you will be exercising how to improve tests' speed, how to make them completely independent, besides increasing the coverage of functionalities being exercised by automated tests.

By the end of the course, you will be ready to put all this knowledge into practice in real software projects on a larger scale.

So far, so good?

Go to lesson 2, and let's start to refactor some tests. 🤓