The Codeception blog has recent post they've written up talking about writing better tests for your application and the difference between expectation and implementation as it relates back to meaningful tests.

What makes a meaningful test? This question should always be asked. No matter we write your tests first or tests after, they may stay in a project for years and it is pretty important them to test the things that really matters. Badly written tests can slow us down by constantly failing on each implementation change, and such tests can be written no matter you follow TDD or not. The idea of a test is to ensure that software works and not to freeze it at specific point.

Such situation happens when a test is bound to implementation details. [...] But how to understand what is stable and what is not? We need to use interfaces. Not that one which is written as interface keyword in PHP but a general term: User Interface, API. And that’s what makes unit testing and browser testing similar: we always need to rely on public interfaces for a test.

They give an example of a test that's "bound to implementation details" from the Magento codebase that relies on a specific function implementation (the "makdir" method). This function is a part of the Symfony functionality, not Magento, and what might happen if things change in your application. They note that the main difference is testing for the result versus testing for the behavior of the functionality. The tutorial wraps up by suggesting that the only testing that should be done is on public, well-defined interfaces that are not as subject to change and not copying logic into tests.