Programming

17538 readers

89 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

snowe

Ategon

[email protected]

What does it really mean to test an interface not the implementation? (lemm.ee)

submitted 1 year ago by [email protected] to c/programming

12 comments fedilink hide all child comments

let's say there is a Shape interface.

interface IShape { double Area(); }

A Rectangle class and a Triangle class implement it. Now should i write tests for:

IShape interface and test both implementations in a single test file?
Write tests for Rectangle and Triangle class separately, testing their implementation of Area() ?
Do something else?

From what I see I am testing implementations either ways. How do you even test an interface without testing the implementation? Can someone please help clarify my doubts? Thanks!

you are viewing a single comment's thread
view the rest of the comments

[–] asyncrosaurus 7 points 1 year ago

It's a form of Black-Box Testing, essentially you want to validate expected behavior. Implementation can change, but your outcome should remain the same.

This is a big target for Test Driven Development, since your first step is to write the test with the expected outcome, then you write the most basic implementation, and when you can verify the behavior, then you are free to re-factor to improve implementation knowing your test will tell you if the behavior changes with each internal change.