Merge pull request #8 from ReCoded-Org/testingmodule

Module 5: Testing

Author: Shrreya

module5-testing/assets/test-pyramid.png

@@ -0,0 +1,22 @@
+# What is a test?
+In programming, a test refers to a piece of code that can be run to verify the
+behavior of a program. For example, if you write a function, and you want to be
+sure that it works for various inputs and outputs, you can write a test for this
+function.
+
+Tests themselves are code. At larger companies, every piece of submitted code
+needs to submitted with a corresponding test. A general rule of thumb is that,
+if you change a line of your code so that the behavior is wrong, a test
+somewhere should fail, so that such a mistake can be caught.
+
+Tests are an important part of many companies' infrastructure for development.
+Generally, humans are not manually running these tests, though you may manually
+run it before sending a PR or while working on the test. In a process called
+**continuous integration** (CI), these tests will automatically run after every
+pull request is proposed. This means that generally, if your code and pull
+request are not passing the tests, it cannot be merged in.
+
+There are many types of tests: unit tests, integration tests, screenshot tests,
+and so on. In a later section, we will talk about some of these types of tests.
+Most commonly, we will refer to unit tests, which are the most frequent type of
+tests.

module5-testing/r1-what-is-a-test/README.md

@@ -0,0 +1,53 @@
+# Why is testing important?
+
+You may think it is sufficient simply to manually test your code.
+
+There are a few reasons testing is very important when it comes to a growing
+codebase. You should not imagine the situation where you are working on a
+project with one or two people, but a situation where you are working with a
+larger team and with code that the company will use the code long after you leave. You
+may not be at the company five years later, or you may forget what the code does
+in six months.
+
+## Correctness
+Most obviously, a test is used to verify the correctness of the code. If you
+have ever changed your code then had to test three or more cases manually, then
+you are familiar with the fact that it is quite cumbersome to repeatedly check
+manually. Not only that, it's very easy to forget to check some case when a
+human is doing it by hand.
+
+In contract, when you write a test, you simply need to run a command in order to
+initiate the tests again, rather than repeating some steps to ensure that your
+code is working.
+
+If you work at a company with code review, consider the perspective of the
+person reviewing your code: how do they know your code doesn't have bugs? How do
+they know it works correctly? If your code is submitted along with tests, the
+reviewer can be aware of exactly what you have or haven't verified about your
+code.
+
+## Ease of change
+Have you ever
+felt scared to change code, because you weren't sure if it would still work for
+all the cases after you changed it? With a good test suite, this fear generally
+doesn't exist. Even if the code is rewritten but the same tests pass, indicating
+that the new code has the same behavior, one can feel a lot more secure about
+rewriting the code.
+
+Having good tests allows code to be changed in a more robust fashion. When the
+same tests pass, a developer can be more sure (perhaps not completely sure,
+depending on the tests) that changing the code did not break anything.
+Additionally, it allows people who are not familiar with the code (say, your
+teammates who work on related code, or someone who is responsible for your code
+five years later) to more easily work with the code.
+
+## Documentation
+A well-written test suite serves as documentation. Again, imagine you have just
+joined a company, and you don't know what a function or component does. In fact, if you want to
+understand what a piece of code does, it's often more productive to go read the
+tests first, rather than the code itself.
+
+In the next section, we'll look an
+example of a test, which will help illustrate how the tests themselves can be
+used to document the code.
+

module5-testing/r1.1-why-is-testing-important/README.md

@@ -0,0 +1,100 @@
+# Example code
+
+In this section, we'll take a look at some example code for tests. It's possible
+you've never seen a unit test before, but you'll find that they're actually
+quite readable, even without knowing the framework.
+
+Let's take a look at this example from
+[Jest](https://jestjs.io/docs/getting-started), one of the most popular testing
+frameworks in JavaScript. Most testing frameworks work in approximately the same
+fashion, simply using different syntax.
+
+```javascript
+test('adds 1 + 2 to equal 3', () => {
+  expect(sum(1, 2)).toBe(3);
+  });
+```
+
+What does this test do? To start off, consider what a function called `sum`
+should do. Even though we can't see the implementation, this is an example of
+how simply reading the test can tell you how the function should behave.
+
+In this test, when the sum function is given the arguments `sum(1, 2)`, we call
+a function `expect` and assert the result `toBe` `3`. Even above that, there is
+a written string (anything can be written there), that tells us that `adds 1 + 2
+to equal 3`. Again, even though we have no idea how sum is written internally
+(although in this case, writing such a function should be quite trivial), **only
+from reading the test**, the behavior of the function is documented in some
+fashion.
+
+Let's continue reading some tests, without even looking at the
+implementation of the tested functions for illustrative purposes.
+
+In this example, let's look at the function `absolute`. You may be able to guess
+what the function does from the name, but if not, read the code below, and try
+to figure out what it does.
+
+```javascript
+describe('absolute', () => {
+    it('should return positive number if input positive', () => {
+        const result = absolute(1);
+        expect(result).toBe(1);
+    });
+    it('should return positive number if input negative', () => {
+        const result = absolute(-1);
+        expect(result).toBe(1);
+    });
+    it('should return zero if input is zero', () => {
+        const result = absolute(0);
+        expect(result).toBe(0);
+    });
+});
+```
+
+In this example, the `describe` function is used to group together a related set
+of tests. Note how the code almost reads like a written description of the
+behavior of the test.
+
+Finally, let's read one more example of a slightly more complex test, written in
+TypeScript. Again, understanding every line is not important, and some
+implementations, such as `makeExpressRequest`, have been omitted. But the
+important part is to try to read the test and see how it helps us understand the
+behavior of a function.
+
+```typescript
+describe('makeExpressRequest()', () => {
+  it('should return token when cookie token is provided', () => {
+    const request = makeExpressRequest('111.222.333', null);
+    expect(getToken(request)).toStrictEqual('111.222.333');
+  });
+
+  it('should extract token when bearer schema is provided', () => {
+    const request = makeExpressRequest(null, 'Bearer xxx.yyy.zzz');
+    expect(getToken(request)).toStrictEqual('xxx.yyy.zzz');
+  });
+
+  it('should throw error when the both are provided', () => {
+    const request = makeExpressRequest('111.222.333', 'Bearer xxx.yyy.zzz');
+    const expectToThrow = async () => getToken(request);
+    expect.assertions(1);
+    return expectToThrow().catch((e) => {
+      expect(e).toBeDefined();
+    });
+  });
+
+  it('should return null if none is provided', () => {
+    const request = makeExpressRequest(null, null);
+    expect(getToken(request)).toBeNull();
+  });
+});
+```
+
+Try to answer the following questions about the above example:
+* What does the first argument to `makeExpressRequest` represent?
+* What does the second argument represent?
+* Are you supposed to pass in both arguments at once?
+* If you pass in the second argument, what does it do to the argument?
+
+By reading the tests in this section, this has given you a more concrete
+understanding of what tests may look like, how they verify correctness, and how
+they help others understand the behavior of a function.

module5-testing/r1.2-example-code/README.md

@@ -0,0 +1,16 @@
+# Testing Philosophy
+In this section, we'll discuss some aspects of testing philosophy. There are
+many different ways to approach testing.
+
+In real life, you may perhaps work at
+companies that do almost no testing (this is not good, but it is the reality).
+This is especially true in smaller companies. You may work at a company that
+chooses only to test certain components or write certain types of tests.
+Finally, as mentioned previously, at some companies, especially bigger ones, you
+may be required to write tests so that every line of code is covered by a test.
+
+Simply writing a test is not sufficient: there are also good and bad ways to
+write tests. In the sections ahead, we'll consider some additional factors about
+the testing process and the quality of tests.
+
+

module5-testing/r2-testing-philosophy/README.md

@@ -0,0 +1,50 @@
+# Test-driven Development
+
+**Test-driven development** (TDD) is a process where developers write the tests first,
+**before** writing the code. As we saw in the last section, the tests alone can
+be sufficient for specifying the behavior of the function.
+
+Even to modify existing code, a test would be written first under this
+philosophy. For example, if you had an `if` statement in your code already, but
+you wanted to add an `else` branch, under TDD, you would first write a test for
+that `else` branch, and then write the actual code. As mentioned before, at the
+highest levels of testing, a mistake in any line of code should be caught, and
+TDD facilitates this.
+
+## Why TDD?
+
+First, TDD requires the developer to first think
+about the behavior of the tested code and how it will be used, rather than
+rushing head-first into writing the code. Perhaps you may have experienced
+writing code and realizing later that the code you wrote was not quite what you
+needed. When you think carefully first about the behavior of the code as in TDD,
+this situation is often avoided.
+
+Second, as developers must write tests with every code, TDD requires developers
+to write tests and puts developers in the habit of writing tests, which is
+generally healthy for the robustness of a codebase. If TDD was not present,
+depending on the company, developers may be less strict about writing tests.
+
+## Is TDD used in the real world?
+Many companies do adopt TDD, although in practice, this is a minority of
+companies. TDD is far from a perfect philosophy: it does not guarantee good test
+coverage and it may even encourage developers to write sloppier tests so that
+they can simply start coding faster.
+
+However, as with all things
+in life, understanding the perspective of TDD is still extremely useful.
+But as all things in life, learning different perspectives is useful.
+TDD is on the very rigorous end of the role of testing in
+development. In reality, you will probably end up somewhere in between --
+perhaps sometimes you will think about the tests first, or you will think in
+your head about what will be tested, even though you may not be required to
+actually write the tests as you would in TDD.
+
+The reason that understanding or trying test-driven development is helpful is
+because even if you do not work at a company that adopts test-driven
+development, it will encourage you to think about success and failure cases
+while you write your code. **This is a crucial part of the programmer's
+mindset.** As you become a more experienced programmer, you will try to predict
+issues; test-driven development aids greatly with this mindset, since it
+encourages you to write the test and think about these scenarios before writing
+the code.

module5-testing/r2.1-testdriven-development/README.md

@@ -0,0 +1,111 @@
+# Properties of a good test
+As mentioned previously, simply writing a test is not the same as writing a good
+test. In this section, we'll examine some properties of what makes a good test.
+
+## Size: Focused tests
+A well-written test should not test too many things at once. In general, test
+cases should be well-isolated and have a [single
+responsibility](https://en.wikipedia.org/wiki/Single-responsibility_principle)
+or intention.
+
+Consider the previous example of the `absolute()` function. Suppose the test
+instead looked like this:
+
+```javascript
+describe('absolute', () => {
+    it('should correctly handle inputs', () => {
+        const result1 = absolute(1);
+        expect(result0).toBe(1);
+        const result1 = absolute(-1);
+        expect(result1).toBe(1);
+        const result2 = absolute(0);
+        expect(result2).toBe(0);
+    });
+});
+```
+
+Now compare this to the original. Which one do you find more readable and
+organized? While this is a simple example, separating the cases for clarity
+becomes especially important with more complex functions.
+
+```javascript
+describe('absolute', () => {
+    it('should return positive number if input positive', () => {
+        const result = absolute(1);
+        expect(result).toBe(1);
+    });
+    it('should return positive number if input negative', () => {
+        const result = absolute(-1);
+        expect(result).toBe(1);
+    });
+    it('should return zero if input is zero', () => {
+        const result = absolute(0);
+        expect(result).toBe(0);
+    });
+});
+```
+
+## Redundancy: avoid overlapping test cases
+As a related topic, you usually want to avoid test cases that overlap too much
+with existing test cases. For example, consider the following test case for the
+above. Is it useful, or is it redundant, overlapping with one of the test cases
+above?
+
+```javascript
+it('should return positive number if input is large and negative', () => {
+    const result = absolute(-100);
+    expect(result).toBe(100);
+});
+```
+
+This case is redundant. Testing `absolute(-1)` and `absolute(-100)` is not very
+useful; the two test cases overlap. We want to avoid this.
+
+It is often asked how much overlap is okay. Inevitably, some test cases will
+overlap with each other. There is no correct answer here: just know that some
+overlap is okay, but you want to do your best to avoid redundancy by selecting
+test cases that are representative of the cases of your function.
+
+In the
+programmer's mindset, usually there are a set of possible scenarios to consider.
+For example, in the case of the `absolute()` function, there are three distinct
+scenarios that define the behavior: positive, negative, and zero. Whether the
+negative number is large or not makes no difference.
+
+## Thoroughness
+In this module, it was mentioned several times that good test coverage means
+that, if the code is behaving incorrectly, even in one line or in one
+if-condition, some line will fail.
+
+A common problem with tests is that some case is missing. Perhaps when certain
+arguments are passed to your function, it behaves differently. A good suite of
+tests will make sure to cover these cases.
+
+## Organization: Arrange-Act-Assert
+Tests generally follow approximately the same pattern, and this has been
+crystallized in a commonly adopted idea called ["Arrange Act
+Assert."](https://automationpanda.com/2020/07/07/arrange-act-assert-a-pattern-for-writing-good-tests/)
+
+1. **Arrange**: Many tests require some type of setup; the setup should come
+   initially.
+2. **Act**: In the act step, the actual behavior being tested should be invoked,
+   such as a function call, an API call, a component render, etc.
+3. **Assert**: Finally, to ensure correctness, assert the expected outcomes.
+   This was seen earlier using the `expect` function. Expect and assert, in this
+   context, are synonymous.
+
+## Additional readings
+This [StackOverflow
+question](https://stackoverflow.com/questions/61400/what-makes-a-good-unit-test)
+gives some interesting insights into what are considered good properties of a
+unit test.
+
+Google has a good resource called *Testing on the Toilet*. On the back of the
+door in every toilet stall at Google, you can find a one-page flyer that
+describes some aspect of testing (that's how important testing is!). These are
+publicized. Some good ones for junior developers are included below:
+
+- [Keep tests focused](https://testing.googleblog.com/2018/06/testing-on-toilet-keep-tests-focused.html)
+- [DAMP](https://www.googblogs.com/testing-on-the-toilet-tests-too-dry-make-them-damp/). Don't overuse functions in test code, focus on readability.
+- [Just say no to end-to-end tests](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html). Avoid overusing tests that connect too many parts of your system.
+