Testing Modules

Writing tests for your code is one of the most important steps in the development process. Good tests will help with documenting your code, QA, refactoring, maintenance, and everything in between.

Everyone agrees that tests are important, but people argue to the ends of the internet about how to fit tests into the development process. Do you write them first? Do you test your code every couple minutes? Do you pass your code off to testers after writing it? In this project you won't worry about any of that, the focus here is to get used to writing and reading tests.

So far in with these projects we've talked about specs (args, return, behavior) as the measure of code - any code matching the same specs is interchangeable. In this project you will take this idea to the next level:

The tests define the module

This means that the tests you write and publish along with your code are the ultimate guide to your project.

  • Anyone should be able to read your test files and understand what your project does.
  • Any code that passes your tests should be able to replace your module in an application.

Index


Learning Objectives

  • Tests define and document your modules
  • Testing modular code
  • Coming up with Test Cases
  • Integrating tests into a codebase
  • Using test cases to explain yourself
  • Object State
  • Exploring and understanding source code

State

This is a concept that will come up again later when you learn about Functional Programming, and again when you learn React. For now we'll stick to a very basic definition:

  • State is any property in an object.

Pretty simple as far as concepts go, but it becomes complicated in practice when objects are changing their values all the time. As you move through your developer journey you will probably come to appreciate the simplicity that comes with stateless design. The simplest instance of stateful vs stateless design is objects vs pure functions.

In this project you'll experience first-hand one of the realms where stateful objects are more difficult to deal with than pure functions: Testing.

TOP


Specifications

Use Tressa.js & Istabul to write tests for you PJS Todo List. You will be expected to write tests for both the Synchronous and Asynchronous versions of your application. These tests will be added to their respective branches. ie. The async tests will be added to the async branch, the synchronous tests will be added to the most recent syncronous branch.

First read through the Testing articles and test library examples.

Then copy the Mix & Match Operations app and write your own tests for it:

  • Sync source code & tests in one folder
    • Unit tests for the smallest bits: each file/component
    • Behavior tests for the largest bits: runtime code after it is built
    • A new section in the README: Code coverage & % Passing tests
  • Async source code & tests in another folder
    • Unit tests for the smallest bits: each file/component
    • Behavior tests for the largest bits: runtime code after it is built
    • A new section in the README: Code coverage & % Passing tests
  • An updated README
    • Include instructions for running the tests
    • Updated Notes section
    • Anything else you'd like to put in there
  • /code-reviews
    • Ask at least one person for a code review

TOP


Resources

Assert:

Testing:

Tools:

Code to Study:

Next Steps:

TOP


Assessment

links to google forms links to repo if there is a larger code-based assessment

TOP



results matching ""

    No results matching ""