I can't really say, but if you read The Clean Coder we might get on the same page. fwiw, what I mean when I say "don't test the implementation," is that your t

I can't really say, but if you read The Clean Coder we might get on the same page. fwiw, what I mean when I say "don't test the implementation," is that your test should not test "how" a function or object performs its task when called. tldr; unit tests should test units -- the smallest amount of functionality possible A trivial example might be an object that retrieves some data from a persistent store and prints it out. It might have a "fetch" method whose argument is a key in the data store. You could easily write a test case that checks when "fetch" is called that the data is written to the standard output stream. It would pass and you could go home after a hard day of work. But if the requirements change and you need it to write to a socket instead and format the data for a binary stream -- you'll have to modify the "fetch" method and the tests. If we were clever though we'd realize that when we wrote the test to see that "fetch" output its result to standard out we were actually asking the object to do too much and our test was testing several different units of work that could be broken down. Ideally our hypothetical object would take a couple of callable objects that handle things like printing data to streams and formatting it. Then our test for fetch only has to test one small "unit" of functionality -- not several units (retrieving data, formatting it, printing it to a stream). hth