# Testing --- ### Bugs Code will inevitably contain bugs :bug: ```javascript const add = (a, b) => a - b; ``` --- ### Real-life bug  Grace Hopper discovered a moth stuck in a Harvard relay in 1947 ###### American computer scientist, US Navy rear admiral, One of the first programmers of the Harvard Mark I computer, --- ### Bugs Code has _user requirements_. Buggy code doesn't meet those requirements  --- ### Bugs Buggy code frustrates users, loses businesses money and can have deadly real world effects.  --- ## Manual testing We can manually check our code fulfils the user requirements. However this is time-consuming and error-prone. --- ## Testing with code Code is great for automating repetitive processes: ```javascript if (add(4, 5) !== 9) { console.error("Fail: add(4, 5) should return 9"); } ``` --- ## Testing frameworks That example works, but doesn't scale well. 3rd party tools give nicer feedback:  --- ## Different types of testing 1. Manual testing (QA) 2. Unit testing 3. Integration testing 4. End-to-end testing --- ### Manual testing Having a person check a feature works correctly before it goes live. Companies often employ Quality Assurance engineers. --- ### Unit testing Testing small, simple blocks of code in isolation (like our `add` test above). Can have 100% passing unit tests and a broken app though. Note: - Easier to isolate issues from the more complex overall system - Easy to miss problems that result from the more complex overall system --- ### Integration testing Testing features made of several units all together. Often interacting with and checking the real UI. Note: - Can be harder to isolate features, especially network requests etc - Gives you a better idea of whether something really works - Can cover much more code in a single test --- ### End-to-end testing Testing the entire site using a real browser. It's like automated-manual-testing :laughing: Note: - Usually the highest confidence that the real system will work - Still limited to certain browsers - Can be flaky due to timeouts etc so sometimes limited to "happy path" tests only --- ## Why test? Other than preventing bugs when we write code. --- ### Refactoring _Changing_ code is sometimes harder than writing it (especially someone else's code). Tests can alert us if we broke something. --- ### Problem solving Some devs find it easier to solve problems by writing tests first. This can help you catch edge-cases you wouldn't have thought of. --- ## Writing good tests Think of tests as bug reports. What do you want a failing test to tell you? 1. What part of your code failed? 1. What should that code do? 1. What did it do instead?