Unit Testing... You are doing it...



  • So one day there had to be a few changes to the database which's EntityFramework update broke a few UnitTests.
    As lazy as i am i just commented them out and marked them to be done for later.

    So this sad day has come up recently and i remembered why i didn't do it immediately.
    The Code was very hard to read and sometimes a minor wtf itself.

    Major wtf was that almost every Method was completely encapsulated in 2-4 Layers of below if-else statement.

    var person = EfContext.Persons.Where(x => x.Any()).OrderByDesc(x => x.Id).FirstOrDefault();
    If(person != null)
    {
    //Same if here again a few times, insert that 50-250 lines of code
    }
    else
    {
    AssertUnObstrusive("no data");
    }
    

    Next thing i stumbled upon was the testing for our InsertCustomer StoredProcedure.

    For every Test the same ~11 Method variables were declared again. (same values of course!).
    Also the Test itself was really questionable:
    For every Parameter where null was not allowed he try/catched if there is thrown an exception.
    If exception gets thrown everything is fine.
    Well we already check for null in stored procedure also the columns arent nullable.
    So if someone changed BOTH the unit test will tell us, but i dont think anyone will change both if it isn't really intended...



  • @CodeClown said:

    As lazy as i am i just commented them out and marked them to be done for later.

    • That should be sufficient reason to be out of work (unemployed) immediately. [Marking as known failure with a proper link to a backlog item - so that they still show in every test run, but do not cause the test run to fail - MIGHT be acceptable]


  • @TheCPUWizard said:

    with a proper link to a backlog item

    Implying we have one..

    Anyway you are right, in a proper managed Product where someone cares about the UnitTests this is what I should have done.


Log in to reply