Principles, practices, patterns, and tips from the trenches
Are you a software engineer that already knows how to write automated tests, but wants to get better at it? This is the course for you.
What you’ll learn
- The most common real-world trade-offs in software testing.
- Different techniques to engineer more rigorous test cases.
- Decide between unit, integration, or system tests, as well as when or not to mock.
- Design highly testable units of code.
- Understand what makes it easy for developers to write tests.
Course Content
- Introduction –> 3 lectures • 15min.
- Engineering strong tests –> 7 lectures • 50min.
- Getting good feedback from our tests –> 7 lectures • 30min.
- Mocking –> 5 lectures • 19min.
- Designing for testability –> 4 lectures • 13min.
- Engineering high-quality test code –> 4 lectures • 12min.
- Other testing dilemmas –> 6 lectures • 24min.
- Good bye! –> 1 lecture • 1min.
Requirements
Are you a software engineer that already knows how to write automated tests, but wants to get better at it? This is the course for you.
This course isn’t about teaching you some testing tool or framework. It’s much bigger and deeper than that. It’s about explaining to you all the principles, practices, and patterns of software testing, their advantages and disadvantages, so that you can write very strong tests that are actually able to find bugs, in a very productive way.
This course addresses topics like:
- How to write test cases that go beyond the happy paths?
- When to go for unit testing and when to go for integration testing?
- How can I use code coverage to help me improve my tests (and finally stop hating it!)?
- What’s the secret to write many tests?
- How to make tests that run fast and are simple?
- When to mock, and when not to mock something?
- What’s key to design testable systems?
- How can I fight flaky tests?
- How to test micro services?
- How to test legacy systems?
- What’s the role of QAs if I’m the one writing tests?
- … and many more!
This course isn’t focused on one specific technology or programming language, and everyone can benefit from it. These principles, practices, and tips emerge from my almost 20 years of experience in helping teams write better tests.