locked
Unit and Integration Testing RRS feed

  • Question

  • I have some questions when it comes to Unit and Integration testing for business logic.

    I have a multi tier design using EF as the data layer.  The Business Logic layer consumes services provided by the data layer.  The business logic layer is in turn consumed by a multitude of applications as the presentation layer.  This includes Windows Services, Rest Services, ASP.Net MVC apps, and WPF apps (MVVM), and WF apps.

    My question is how to Assert whether the integration test passes or fails?

    For example:

    1: A user uploads and image through a third party application.  This image is stored in a SQL Server database.  I have created model objects in the data layer and have unit tests for the model objects.

    2:  The business logic reads the image data.

    3:  The business logic uploads the image to a SharePoint Library using SharePoint Web Services.

    4: The business logic assembles an email and delivers it to a specific group of recipients.

    How is one supposed to test this?  I write a test, much like a Unit test, that exercises all the functions above, but the only way that I can determine the success or failure is to manually check the SharePoint Library for the image, and then go the recipients to see if they received the email.


    Bill Behning

    • Moved by CoolDadTx Monday, December 23, 2013 3:24 PM Testing related
    Monday, December 23, 2013 2:25 PM

Answers

  • It sounds like your approach is appropriate.  Unit tests are for verifying individual blocks of code are working.  Integration testing is verifying a workflow.  As such you should verify the end result of the workflow. It is insufficient to simply test that the code at the end of the workflow is working because that is just a unit test. 

    Michael Taylor
    http://msmvps.com/blogs/p3net

    • Proposed as answer by Amanda Zhu Thursday, December 26, 2013 9:04 AM
    • Marked as answer by Amanda Zhu Wednesday, January 1, 2014 2:12 AM
    Monday, December 23, 2013 3:23 PM
  • In an ideal world you're using an interface to talk with your mail service.  In a test you'd mock the mail service and confirm that it receives the email (to be sent) that you expected.  This is sufficient to prove that email is working without having to test the network infrastructure (which can be unreliable for testing).

    If you really want to test that mail is working then you can set up a local SMTP server (built into Windows).  The local SMTP server stores emails on the local file system.  You can then query the file system to confirm that the email was sent to the SMTP server.  This should be sufficient to verify the integration since any failure after that is either network or address related.

    • Marked as answer by WRBehning Thursday, January 2, 2014 9:17 PM
    Thursday, December 26, 2013 3:52 PM

All replies

  • It sounds like your approach is appropriate.  Unit tests are for verifying individual blocks of code are working.  Integration testing is verifying a workflow.  As such you should verify the end result of the workflow. It is insufficient to simply test that the code at the end of the workflow is working because that is just a unit test. 

    Michael Taylor
    http://msmvps.com/blogs/p3net

    • Proposed as answer by Amanda Zhu Thursday, December 26, 2013 9:04 AM
    • Marked as answer by Amanda Zhu Wednesday, January 1, 2014 2:12 AM
    Monday, December 23, 2013 3:23 PM
  • So, the only way to validate intetration tests is to manually verify the expected results?

    Bill Behning

    Monday, December 23, 2013 3:48 PM
  • You don't have to do it manually.  You can use whatever APIs are available (that you didn't write) to confirm the data was updated correctly. 
    Monday, December 23, 2013 5:20 PM
  • That makes sense for the Web Service API, but what about email?  The only way I can figure out to validate the test is to manually verify with the recipient that the email was received.

    Bill Behning

    Thursday, December 26, 2013 3:11 PM
  • In an ideal world you're using an interface to talk with your mail service.  In a test you'd mock the mail service and confirm that it receives the email (to be sent) that you expected.  This is sufficient to prove that email is working without having to test the network infrastructure (which can be unreliable for testing).

    If you really want to test that mail is working then you can set up a local SMTP server (built into Windows).  The local SMTP server stores emails on the local file system.  You can then query the file system to confirm that the email was sent to the SMTP server.  This should be sufficient to verify the integration since any failure after that is either network or address related.

    • Marked as answer by WRBehning Thursday, January 2, 2014 9:17 PM
    Thursday, December 26, 2013 3:52 PM
  • Yep, I have the email service built around an interface, and it has been unit tested.  I like your suggestion about the local smtp service.  I was not aware that it saves emails to the local file system.  This should close the loop for me.

    I wanted to get some assurance that I was going in the correct direction.  Thanks for the help.


    Bill Behning

    Thursday, January 2, 2014 9:21 PM