locked
How do I approach this from a TDD mindset? RRS feed

  • Question

  • Hi,

    I'm trying to get a handle on TDD and unit testing in general. I understand it for simple cases the books and tutorials usually show but I'm not sure about how to approach a more difficult, real-world problem I'm working on now.

    Part of the processing I need to write, I'll describe briefly, is to have code that will extract files from a Zip file and verify that each of the extracted files is a valid JPG file. The programming part of this isn't a problem. I'm using version 4.5 of the framework so I can use the ZipFile, ZipArchive, etc classes from System.IO.Compression to handle the zip file. I can look for the JPG magic number or use img.RawFormat.Equals(..) to verify the JPG.

    The problem I'm having is how to do this from a TDD point of view. The whole process involves processing external files. How do I unit test this? I don't want to include test files in my test project, that doesn't feel right. Maybe some mocking would be involved but it seems like I'd be mocking the whole process so I wouldn't really be testing anything.

    I'm not asking anyone to write code for me. I'm just looking for some advice from an experienced TDD'er on how to approach a problem like this.

    Thanks
    Terry
    Monday, August 18, 2014 3:00 PM

Answers

  • Exactly, sorry for such a poor reply.

    For every behavior you described I will create the tests I think will be usefull and then the code. And after that, I will try to create the tests that checks that those classes fit well in the main class that make all the process.

    So, for the JPGChecker i will create two tests: one for a valid file, and one for a wrong one. As you said, it seems it is needed a class to check if a file exist, so I will test it before write the code, and a class for the compression.

    Finally the main class will use those three classes, so i will mock them to write the tests needed to check what happen with the process, for example, if the file does not exist, or is not a valid jpg file. These last tests will tell us if the design we had in our head and that now is coded is good or not. It could be saw  as a waste of time, but rigth now we have tested the jpgchecker, the filehelper and compression classes.

    If it does not work, we had learned a way of how to don't do it.

    Hope this clarify something!


    Try-Fail-Learn-Improve http://speakingin.net



    • Edited by JuanLao Tuesday, August 19, 2014 6:40 PM
    • Marked as answer by TerryDiederich Wednesday, August 20, 2014 4:32 PM
    Tuesday, August 19, 2014 6:38 PM

All replies

  • Hi, I think this thread could help http://social.msdn.microsoft.com/Forums/vstudio/en-US/9c5aad3a-839c-4bfb-bc6f-a671d8afa9ba/mocked-objects-or-mocking-interfaces?forum=vsunittest

    In your scenario, it could not be usefull to test the compression process, nor the JPG checking process. It will be usefull if you develop the compression libraries or the JPG checker.

    It seems the TDD process will be aplicable to the interaction between the classes you will need, Imagine ZipChecker, and JPGChecker, and TDD could tell you if the interactions and classes are good.

    Please check this other thread that could be helpful too: http://social.msdn.microsoft.com/Forums/vstudio/en-US/893eb887-a6dd-419a-ac6a-7dda8da87c1f/developing-an-application-using-tdd-where-do-i-begin?forum=vsunittest

    Hope this helps!


    Try-Fail-Learn-Improve http://speakingin.net


    • Edited by JuanLao Tuesday, August 19, 2014 6:33 AM
    Tuesday, August 19, 2014 6:32 AM
  • Thank you for the reply!

    When you say "it could not be useful to test the compression process, nor the JPG checking process.", I'm not sure I understand. I guess that means (in this case) I don't need to test the .NET Framework code to check to see if a file is a valid JPG file?

    So I could wrap the following code in some sort of JPGChecker interface and class, with appropriate error checking code.

     System.Drawing.Image img = System.Drawing.Image.FromFile(filename);
     return img.RawFormat.Equals(System.Drawing.Imaging.ImageFormat.Jpeg);
     
    Then when testing ZipChecker I could mock JPGChecker to return a true and a false to test ZipChecker. I would be checking the interaction between ZipChecker and JPGChecker.

    Am I not writing tests to check the JPGChecker code or am I just assuming the .NET code works? Is that what you mean by 'not useful'?

    What if I add code in JPGChecker to test to make sure the filename is valid, that the file exists and is not empty? Would I not want to test how I am using the .Net code?

    Maybe TDD involves organizing my code in a different way that I have in the past?

    Thanks again.
    Tuesday, August 19, 2014 2:44 PM
  • Exactly, sorry for such a poor reply.

    For every behavior you described I will create the tests I think will be usefull and then the code. And after that, I will try to create the tests that checks that those classes fit well in the main class that make all the process.

    So, for the JPGChecker i will create two tests: one for a valid file, and one for a wrong one. As you said, it seems it is needed a class to check if a file exist, so I will test it before write the code, and a class for the compression.

    Finally the main class will use those three classes, so i will mock them to write the tests needed to check what happen with the process, for example, if the file does not exist, or is not a valid jpg file. These last tests will tell us if the design we had in our head and that now is coded is good or not. It could be saw  as a waste of time, but rigth now we have tested the jpgchecker, the filehelper and compression classes.

    If it does not work, we had learned a way of how to don't do it.

    Hope this clarify something!


    Try-Fail-Learn-Improve http://speakingin.net



    • Edited by JuanLao Tuesday, August 19, 2014 6:40 PM
    • Marked as answer by TerryDiederich Wednesday, August 20, 2014 4:32 PM
    Tuesday, August 19, 2014 6:38 PM
  • Thanks again. That helps.

    Terry

    Wednesday, August 20, 2014 4:32 PM