Many companies today are using test driven development or TDD to create their web software.
TDD has become very popular because it prevents issues and bugs in the future, it can increase the efficiency of your work flow, and help teams communicate the intentions of their code's functionality. A downside of TDD is that it takes longer to get a project started, so it requires a little bit of up-front patience.
The basic flow of TDD
- Create a test (make sure it fails so you don't get a false positive)
- Write code to try to pass the test
- Once passing, refactor where possible in both test and implementation code
- Create the next test and repeat
Readable -> Make it clear what the test's actual and expected behavior is, and why.
Isolated -> Make sure tests only cover a particular segment of code, because you don't want certain tests interfering with other tests. If interference occurs, you may not know if the test failed due to your target code or from a previous test.
Thorough -> Prepare for edge cases, like if someone enters in something totally unrelated to the expected input. For example, what if someone tries to submit an empty form?
Explicit -> This ties in with code readability. If someone looks at the test, they should be able to require little setup.
Unit test -> small pieces of functionality
Integration test -> checking if all the smaller tests/code work together such as seeing if the app communicates with an API (Application programming interface) correctly
End-to-End -> tests entire application from user viewpoint (examples: Selenium or Cypress.io)
(usually in the form of libraries)
- Testing environment/test runner (the place to run tests)
- Testing framework (Ex. Mocha or Jasmine, organizes/holds your test code)
- An assertion library (this allows you to not have to write tons of if-statements, this does the actual verifications of test results)