Software testing basics: check behavior and failures

A code change appears to work, but an empty input or failed dependency can still break it. Automated tests run repeatable checks so those mistakes are caught before someone relies on the changed behavior.

A unit test checks a small piece in isolation. An integration test checks how pieces work together, such as a program talking to a database. Start with important user-visible behavior and a few likely failures. A test is useful when a meaningful bug makes it fail, not just when it repeats the code's current steps.

Try it in a lab

For a small parser or configuration tool, write cases for a valid input, an absent value, malformed data and a failure from a dependency. Add one integration check for the real boundary the tool uses.

Check your understanding

Deliberately break a behavior and verify that the relevant test fails for a clear reason. Explain what the test does not exercise.

Before you start

A mock can hide a wrong assumption about the external system. Keep important boundary checks against a disposable real service where practical.

Read the official guide

Use the project documentation for version-specific commands and prerequisites. Record the versions and results of your own exercise. This page proposes a learning activity; it does not report a Kubedex test.

This is a newly written study reference at an address from the original Kubedex course outline. The original lesson was not recovered. It does not include course enrolment, progress tracking or a certificate.