Applying Model-Based Testing for Fault-Injection in cloud services – Part III

2-services model

Interestingly enough, when modeling more than one service, the model will also generate tests that verify services continue functioning even when others go down. Essentially what we are checking here is that we don’t have any unnecessary dependencies between the services, and that a service won’t hang because another one is down.

When designing models including more than one service the state-space can rapidly explode. Consider adding just another service: Payment Service into the model which we depend on upon check-out.

We extend our model by adding:

    public class PaymentService : ModelService

    {

        public override string Name { get { return "Payment"; } }

        public void ProcessPayment()

        {

            ConditionRunning();

        }

    }

And changing the model to:

    static class WebshopModelProgram

    {

        static ShoppingCartService cartService = new ShoppingCartService();

        static PaymentService paymentService = new PaymentService();

        [Rule(Action = "AddToCart()")]

        static void AddToCart()

        {

            cartService.AddItem();

        }

        [Rule(Action = "ProceedToCheckOut()/result")]

        static bool ProceedToCheckOut()

        {

            if(cartService.Count() == 0)

                return false;

            cartService.Empty();

            paymentService.ProcessPayment();

            return true;

        }

Applying Model-Based Testing for Fault-Injection in cloud services – Part II

Okay, so I have to admit I’m mixing things up a bit here. This week I wanted to go to a 2-service model, but I realized that would be jumping ahead of things. Instead I want to take the next steps in actually implementing the shopping cart service and the model interface to this service, as this has some interesting challenges.

First the service…

Shopping cart service

The shopping cart service is a Windows Azure WCF Service Web Role project. It implements a very crude interface. You can add an item to the cart, reset it (empty it), retrieve the number of stored items and proceed to checkout (which includes emptying the cart). The interface is:

    public interface IShoppingCart

    {

        /// <summary>

        /// Empties the shopping cart

        /// </summary>

        [OperationContract]

        void Reset();

        /// <summary>

        /// Adds the item with given name to the shopping cart

        /// </summary>

        /// <param name="item">Name of item to add</param>

        [OperationContract]

        void AddItem(string item);

        /// <summary>

        /// Returns the number of items currently in the cart

        /// </summary>

        /// <returns>Number of items in cart</returns>

        [OperationContract]

        int GetCount();

        /// <summary>

        /// Continues to payment input, and empties the shopping cart

        /// </summary>

        /// <returns>False if no items are in the cart</returns>

        [OperationContract]

        bool ProceedToCheckout();

    }

The service can be started from within Visual Studio where you can debug it, or you can generate an Azure ASP.NET Web Role that consumes it.

Writing tests against a service is piece-of-cake. You simply add a service reference to the test project and create a static instance of the service client, which you can then call. The adapter layer of our model based tests will simply call the appropriate service method for each action, with the exception of the “KillService” and “RestoreService” rules that are special.

The implementation of a shopping cart service can be found in the appendix [1]. 

These actions are a bit more tricky to implement...