And here I am again, reading test cases that basically boil down to:

$testCase->foo = "bar";
$this->assertEquals($testCase, "bar");

$testCase2->foo = null;

Why would anyone feel the need to write these kind of tests? They don't do anything. If I set up my mock a certain way, of course I will have that data, esp. if the unit under test only applies the data AS IS. (Funily enough through another component that already has the relevant dummy tests in place making these tests extra redundant and obsolete.)

You would think that one test case with dummy data suffices, yet no, there are like 30 examples that lie to you about apparent business logic cases, yet in the end the way you set up the mock decides what you will or won't get.

What's the point?

  • 0
    Well, if it had magic getters and setters.. :)
  • 3
    Yet the following unit test fails:

    $testCase->foo = "bar";
    $this->assertEquals($testCase, "bar");
  • 0
    @rooter I almost wish. The "logic" is rather dumb. The only thing that happens under the hood is that objects (and array of objects) are converted to an array via reflection and the only "transformation" worthy of note is that numeric values are always casted to floats. The rest is stored as is. Nothing special going on. The test case makes it seem like something super important is going on, when in fact, the results only change because the mock was changed.

    It's code for the sake of writing code.

    One unit test with dummy data would have sufficed. (And that one already exists.)
  • 3
    @wick3dpoison depends how the __toString() magic method is implemented.
  • 1
    @wick3dpoison Typo on my side. It should have been:

    $testCase->foo = "bar";
    $this->assertEquals($testCase->foo, "bar");
  • 1
    @wick3dpoison No, doesn't have to. Magic methods can fix that i guess..

    Edit: kwilliams was faster
  • 0
    @kwilliams @rooter Then that unit test is not that vain
  • 1
    @kwilliams Yes, that is the only thing that comes to mind what *might* be worthy of testing. Yet that test case could have been a test case of that value object's tests. No need to tests this inside this "service".
  • 0
    For web applications nothing tests like Cyprus / Selenium.

    I worked at a company with literally everything tested one level deep per function using mocks. In theory it should be OK. But in reality the few cypress tests tested ten times better.

    Mocks are just simple and easy to write. Doesn't take much time but indeed, what do they test often?
  • 1
    @rooter Those tests are great to tell that something is broken but really bad at the why. Unit tests should be the base line of defense but apparently only a subset of developers knows how to write them. Which is funny as unit tests are the easiest tests to write.
  • 0
    Several things....

    Stay away from __get / __set .

    You will fuck up sooner than later.

    I think (hope?) the message parameter was left out to shorten the rant.

    Nothing is more pervert than writing in an test failure message the expected value.

    The message is there to describe the behaviour (!) you test, so you know what should have happened.

    Testing values makes no sense at all, author is right.

    If you want to test automatic behaviour, it should be by invoking the method explicitly.

    __get takes a String with the name of the attribute to test.


    $testValue = 'bar';
    $testClass = new testClass();
    $testClass->Foo = $testValue;

    "__get behaviour, expected value not returned."

    That test case will fail compilation, too - if __get isn't implemented.

    Which makes it obvious.
Add Comment