Test: Is Positive

Here's the specification for a function you don't need to write:

is_positive(n)

Returns True if n is strictly greater than 0, and False otherwise (including for 0 itself — zero is not positive).

Your job: write a unittest.TestCase class, TestIsPositive, with three test methods that verify this specification: test_positive, test_negative, and test_zero. Call is_positive directly (it's already defined and available — you're testing it, not implementing it).

Your tests will be checked two ways: against a correct implementation of is_positive (every one of your tests should pass), and against a buggy implementation (at least one of your tests needs to fail, proving it actually catches the bug).

Walkthrough

Thinking it through

import unittest


class TestIsPositive(unittest.TestCase):
    def test_positive(self):
        self.assertEqual(is_positive(5), True)

    def test_negative(self):
        self.assertEqual(is_positive(-5), False)

    def test_zero(self):
        self.assertEqual(is_positive(0), False)

Three straightforward assertEqual calls, one per method — the actual writing isn't the hard part here. The important thing is which three cases were chosen.

test_positive and test_negative cover the two "obvious" outcomes — a clearly positive number and a clearly negative one. But a specification that explicitly calls out a boundary ("zero is not positive") is telling you where a careless implementation is most likely to get it wrong. An implementation like return n >= 0 would pass test_positive and test_negative just fine — it only disagrees with the correct behavior exactly at 0. Without test_zero, that bug would slip through undetected.

This is the core lesson of writing good tests: it's not enough to test the cases that are easy to think of. Deliberately testing the edges — the boundary values a spec calls out, the empty case, the exact-equal case — is what separates a test suite that merely exists from one that actually catches mistakes.

Sign in to join the discussion.