Showing posts with label Mocking. Show all posts
Showing posts with label Mocking. Show all posts

Tuesday, January 24, 2023

Freemium Mock Web APIs for testing - Beeceptor

Often when we develop we will end up in situations where we need to simulate the real scenario by mocking the dependencies. It may be databases, Web APIs, or container images. There was a separate post on mock container images that echo HTTP. 

Problem

There are scenarios where we may not be having the opportunity to run containers to expose the mock Web APIs. This post about handling such scenarios

Solutions

There are many solutions to address this.

Hosting Web API from our machine

We don't need to code from scratch. Just search in GitHub and we can get many. Simply clone and run.

Using internet-hosted mock Web APIs

This works if our development environment has access to the internet. There are paid as well as freemium services. One such freemium service is Beeceptor. 

Please note this post is not sponsored by Beeceptor also the author is not at all affiliated to the service. Their service saved some time today hence this post.

Some features are below
  • The free tier gives 50 requests per day. 
  • Integrated with Google and GitHub accounts. No need to remember one more password.
  • Support delay even in the free tier.
  • Support custom response headers and status codes.
  • The HTTP responses can be configured quickly using the 'Mocking Rules' editor.

This is not a sophisticated mock Web API provider but it helps us to get quick mocks

Happy mocking...

Tuesday, November 20, 2018

Detecting whether the code is running under Karma test runner

Disclaimer

Putting the disclaimer in the beginning as it is a bad practice to check whether our code is running under the test and do actions based on it. Ideally it should be done via dependency injection and mock objects.

But still to document there is an option to check whether the code is running under test and trying to explain why its needed in one scenario.

How to check code is running by Karma

The idea came from the below SO question.

https://stackoverflow.com/questions/26761928/how-to-check-if-you-are-using-karma

Before going into the code let us take some time to understand Karma. It is a test runner. It runs the JavaScript application by starting browser instance(s). Those instances can be either with UI or headless. Headless means no UI or consider as in memory.

Lets understand the code

function isKarmaRunning(){
  let isKarmaRunning = false;
  if (typeof window["__karma__"] !== "undefined") {
    isKarmaRunning = true;
  }
  console.log(`[bootstrap] isKarmaRunning - ${isKarmaRunning} ${typeof window["__karma__"]}`); // still undefined
  return isKarmaRunning;  
}

It is self explanatory and show the danger itself. It assumes when the code is run by Karma test runner, the window object will get a properly called __karma__. We can detect the presence of Karma by checking that property.

The danger is that in future when Karma decided to stop setting the __karma__ property or change its name, our code will fail.

Thanks to laukok for his question with solution.

One scenario to detect whether Karma is running

This is not a scenario where we must check for Karma. Rather its hack and you are free to suggest how to do it right.

The scenario is where AngularJS and PWA (Progressive Web Apps) are combined. PWA's ServiceWorker feature is used to intercept the web requests to populate cache or serve from cache instead of hitting server. The cache is filled to ensure that the application can be used even without internet connection.

The ServiceWorker has fetch API which is used to intercept the web requests. fetch API hook starts only after the service worker is properly initiated. It may take up to 100ms as per different sources. If AngularJS application is bootstraped before ServiceWorker comes into active mode, it will not catch the web requests hence not cached. The web requests include the requests from ng to get the html views

If the user is still online and use the application, there are chances that those web requests are again intercepted and stored into cache. But what if the user first launch the application and went to offline. The cache is not populated hence error.

In order to work the initialization delay one of the solutions is to explicitly bootstrap the Angular application once the ServierWorker has started. Then the problem is that the tests written will complain that the Angular application is not bootstraped. Then either we need to change all the tests to wait for the ServiceWorker to initialize or have the application changes to do below

If the application is running under Karma, boo Angular immediately. Else wait for the ServiceWorker to initialize.

Too complicated. Isn't it. As an software engineer we should have gone back to original problem and solved the issue by separating the components and directives to separate ng module or one of the other approaches. 

Hopefully once there is enough time to analyze there will be a follow up post with better solution. In mean time feel free to pour your comments.



Tuesday, May 26, 2015

Moq - How to know the number of times a method is called on mocked object

Moq seems a good mocking library for .Net unit tests. It has most of the features a developer needs and pretty much stable and many people are using it. Once I started using it, I never felt a need to another mocking library. Below is one if the scenario which I had to face related to Moq.

Scenario

There is a method which randomly executes operations (IOperation implemented classes) stored in an array. The operations are unit tested independently to make sure there is no problems with them. This method which is in test simply uses Random class to get random number and get an operation from array using that number and invokes the operation.

Ideally speaking we don't need to test the Random class which is part of .Net framework. But why should we avoid unit testing our logic inside the method ? Some tests like 'making sure random value is not above the length of array' etc... So whats the big deal?

Challenge

The unit tests works by Arrange,Act,Assert methodology. First we need to arrange the things, Then act or do the operation by calling the method under test. Finally assert.

When we do the act, we should be knowing what is the output. Then only we can write assert. If we don't know what is going to happen we don't know what to assert.

An Example

Recently I forked ChaosMonkey for .Net and started contributing to it. I made it configurable. Looking into that code might be useful to understand the example better.It contains a MonkeyKeeper and IMonkey interface. MonkeyKeeper is the external interface. When MonkeyKeeper.Unleash() is called it should randomly pick an IMonkey from its monkeys collection and call Unleash() method on it. IMonkey implementations can be easily unit tested to make sure they are doing their duties on Unleash. But how to unit test MonkeyKeeper.Unleash()?

In this scenario, we can assert that the mocked IMonkey objects at least got one call to unleash. But in order to get at least one random calls, we need to call the MonkeyKeeper.Unleash multiple times because Random can return same value multiple times.

Below is one implementation, where MonkeyKeeper.Unleash() is called 5 times which is holding 3 IMonkeys collection.

[TestMethod]
        public void WhenMonkeyListProviderGivesMultipleMonkeysAndUnleashMultipleTimes_UseThoseMonkeysAtleastOnce()
        {
            Settings settings = new Settings();
            ChaosLogger logger = new ChaosLogger("");
        //Arrange
            var mockMonkey1 = new Mock<ParentMonkey>(settings, logger);
            var mockMonkey2 = new Mock<ParentMonkey>(settings, logger);
            var mockMonkey3 = new Mock<ParentMonkey>(settings, logger);
 
            var mockMonkeyListBuilder = new Mock<MonkeyListBuilder>();
 
            mockMonkeyListBuilder.Setup(builder => builder.GetMonkeys(settings, logger))
                    .Returns(new List<ParentMonkey>() {
                        mockMonkey1.Object,
                        mockMonkey2.Object,
                        mockMonkey3.Object
                    });
 
            MonkeyKeeper keeper = new MonkeyKeeper(
                settings,
                logger,
                mockMonkeyListBuilder.Object);
            //Act
            keeper.UnleashRandomMonkey();
            keeper.UnleashRandomMonkey();
            keeper.UnleashRandomMonkey();
            keeper.UnleashRandomMonkey();
            keeper.UnleashRandomMonkey();
            //Assert
            mockMonkey1.Verify(monkey => monkey.Unleash(), Times.AtLeastOnce);
            mockMonkey2.Verify(monkey => monkey.Unleash(), Times.AtLeastOnce);
            mockMonkey3.Verify(monkey => monkey.Unleash(), Times.AtLeastOnce);
        }

Most of the times this test will succeed. But there is no guarantee that it will succeed always because Randon.Next() using inside MonkeyKeeper.Unleash can return same value 4 times and that's why its random. in such scenarios this test will fail. So whats the solution.

Solution

There is no solution to this. If we can predict random number and write asserts, that is not random. So what we can do?

At least make sure, there is some level of randomness in the selection of IMonkeys. Also we can make sure if there are 3 IMonkeys in the collection at least one of the IMonkey's unleash is called. If that is not called or called multiple times, there are some problems in the random selection logic of MonkeyKeeper.Unleash. Whats the problem in doing that?

We have 3 monkeys and we don't know which one will be selected by random logic. But we need to make sure that the unleash is called only once and on one monkey. This clearly tells that normal mechanism of asserting via Verify() and Times will not work. If there is any confusion just try writing that as below

mockMonkey1.Verify(monkey => monkey.Unleash(), Times.AtLeastOnce);
mockMonkey2.Verify(monkey => monkey.Unleash(), Times.AtLeastOnce);
mockMonkey3.Verify(monkey => monkey.Unleash(), Times.AtLeastOnce);

Why the above wont work? when we unleash it may call mockMonkey1. and that line works and test passed. But what about the next lines? They will fail. We cannot put a return statement because next time mockMonket3 might be the one selected. In that case first 2 statements will fail.

Now whats the method? We need to know the number of times a method is called on mocked object. There is no direct way to know that. So we need to use the callback mechanism available in Moq to achieve our aim. Callback function helps to get a hook in our unit test when a particular method is called on mock object. Code goes as below.
[TestMethod]
public void WhenMonkeyListProviderGives3MonkeysAndUnleashOnce_UnleashMustBeCalledOnOneMonkey()
{
    Settings settings = new Settings();
    ChaosLogger logger = new ChaosLogger("");
    //Arrange
    var mockMonkey1 = new Mock<ParentMonkey>(settings, logger);
    var mockMonkey2 = new Mock<ParentMonkey>(settings, logger);
    var mockMonkey3 = new Mock<ParentMonkey>(settings, logger);
 
    int callCount = 0;
    mockMonkey1.Setup(monkey => monkey.Unleash()).Callback(() =>callCount+=1);
    mockMonkey2.Setup(monkey => monkey.Unleash()).Callback(() => callCount += 1);
    mockMonkey3.Setup(monkey => monkey.Unleash()).Callback(() => callCount += 1);
 
    var mockMonkeyListBuilder = new Mock<MonkeyListBuilder>();
    mockMonkeyListBuilder.Setup(builder => builder.GetMonkeys(settings, logger))
            .Returns(new List<ParentMonkey>() {
                mockMonkey1.Object,
                mockMonkey2.Object,
                mockMonkey3.Object
            });
 
    MonkeyKeeper keeper = new MonkeyKeeper(
        settings,
        logger,
        mockMonkeyListBuilder.Object);
    //Act
    keeper.UnleashRandomMonkey();
    //Assert
    Assert.AreEqual(1, callCount, "Unleash Called multiple times");
}

http://stackoverflow.com/questions/16693078/when-using-moq-verify-method-invocation-count-have-failing-tests-error-messa

Tuesday, December 9, 2014

Unit testing - How to verify dependent object's methods are called?

Testing void methods

In one of previous post, we saw what is mocking in unit testing. If the function which we are going to unit test is returning a value also expecting some value from the dependency which we mocked, its easy to test. But how to test a method which doesn't return a value, but successful execution calls a method in the dependency. In other sense we need to know whether a particular method in mock gets called or not to determine the test result.

So this post is aiming at how to test void methods which calls a particular method in dependency. Hope the purpose on why we should check whether a method in dependency is called or not is clear.

If its not clear, lets take one scenario. Sorry my project mates felt it difficult to understand so I am thinking there would be similar kind of developers out there. Others can skip the below story and look at the code.

Take the scenario of saving a Person object into database. There is a PersonRepository class with Save() method. It needs to validate some business rules such as the phone number and email. When we test the void PersonRepository.Save() by writing unit test cases, we must be focused only on the logic inside the Save(), not about saving into database. That will be done by IDataAccess which is a dependency of PersonRepository. We need to make sure that the Save() method is calling IDataAccess.InsertOrUpdate() upon success. 

Below is the code snippet which is ensuring that a method of dependency is called from production code upon success. It uses Moq library.

    public class PersonRepository
    {
        IDataAccess _dataAccess;
        public PersonRepository(IDataAccess dataAccess)
        {
            _dataAccess = dataAccess;
        }
        public void Save(Person person)
        {
            ThrowExceptionIfInvalid(person);
            _dataAccess.InsertOrUpdate(person);
        }
        private void ThrowExceptionIfInvalid(Person person)
        {
            if(string.IsNullOrEmpty(person.EMail))
            {
            throw new ArgumentNullException("e-Mail should not be empty");
            }
            //More code goes here to validate email & phone
        }
    }

Unit test code

        [TestMethod()]
        public void WhenEverythingIsOK_CallIDataAccessSave()
        {
            Mock<IDataAccess> mockDataAccess = new Mock<IDataAccess>();
 
            Person person = new Person() { EMail = "joymon@gmail.com" };
            PersonRepository repository = new PersonRepository(mockDataAccess.Object);
            repository.Save(person);//Test only the logic written inside Save() method.

            //IDataAccess.InserOrUpdate() will be called on success
            mockDataAccess.Verify(mock => mock.InsertOrUpdate(person), Times.Exactly(1));
        }

Happy testing.

Tuesday, November 25, 2014

What is Mock object and Mocking framework in unit testing?

TDD

This is a buzz word in development for some time. TDD got into picture when Agile storm hit the software development industry even though they don't have much relation. Let's look at what is mean by TDD ie Test Driven Development.

As the meaning says the software development process is driven by test in a TDD environment.  Developers need to write automated test case first which will fail obviously. Then write code to make that test passing. When we say automated test case, its again a program which is calling the code / function intended to develop to fulfill the requirements.

Once one test passes, developer needs to think about next scenario and writes test for that scenario. First it will fail, then we will change the production code to pass that test. Finally we will be ending in a scenario where there will be many test cases / test function for one production function. The idea is whatever the developer thinks, it needs to be recorded in the form of test cases. In other words even if, there is not much documentation, by looking at the tests new developers should be able to understand the intentions of particular function.

After all the test cases are completed, the production code needs to be re-factored to standards. Use of proper patterns, making sure its adhering to SOLID principles are coming in this phase. Normally delivery oriented companies or companies want to make more profits and budget constraint projects never go for this step. If they do so  it will surely byte them back in future during maintenance phase of the project.

We talked about writing tests, what is the type of test case or what do they test? Is it load test, functionality test or integration tests? Can we get rid of QA department if we bring TDD methodology?

Never. In TDD we are writing unit tests only. Developer tests his own API to make sure that, his piece of code / function will work as expected in all the scenarios. Other type of test such as functionality testing, integration testing & load testing needs to be carried by the QA / Testing department.

Unit testing

Unit as the name says testing small units of program. In most of the programming languages today,  the smallest unit of program which can be tested is function / method. So we are testing functions via unit testing. We can say its part of API testing as well. But its not full API Testing. API Testing includes more factors. 

Important thing to remember here is, unit test is to test one single unit. Not its upstream or downstream dependencies. 

Why this is more important? If we take any layered application, the business logic is supposed to be in single layer which we normally call as business access layer. Business logic is nothing but  collection of if...else and looping code based on client's requirements. So the unit testing is more applicable on business layer. If we take data access layer, there are not much code expected other than the database interactions and those are pretty static in all the projects. So lets take one scenario to get the idea clear.

Unit testing in real scenario

Suppose, we are developing an address book application. We need to validate names for special characters & validate the Zip code (Pincode / postal code in India) whether its real or not.That validation logic obviously comes in business layer. (Of course UI will have validation but its optional. BL can never avoid it)

In this situation, when we write the test method for BL.InsertPerson(Person p), we will be obviously calling a web service which will return true / false for a given zip code. During development time we will be running the tests so many times and if we try to call that web service all the times, it will take us precious time. So what to do?

Answer is Mock object. In an ideal case, if we are following SOLID principles, there would be an IZipcodeValidator interface with Validate() method. Mock this interface and return true always. So that we can unit test the InsertPerson() method. Then what about the data access layer. The default data access layer will obviously call database and try to save the data in it. But do we really need the database interaction when developing the business layer?

No. Remember we are unit testing single unit of code not its dependencies such as data access or  zip code validator. The aim of the unit tests in this case is to make sure 
  • If the parameters into BL.InsertPerson is wrong ensure there is exception
  • If the parameters are valid, make sure the IDataAccess.Insert() is called.
  • More test scenarios like, 
    • If the data access throws exception BL.InsertPerson should not eat it
    • More (as of me it goes to infinity:))
If we are not calling the real data access, how do we make sure the business layer function is working proper. As we saw above,its the magic of mock object. It knows what to do for particular scenario. How do we create mock objects? Do we need to write mock classes?

Mocking

Wiki says "Mock objects are simulated objects that mimic the behavior or real objects in controlled ways". What does it mean? We are creating some dummy objects (simulated) which can be injected as dependency in the class under test (mimic the behavior). Important thing to remember is without knowledge in dependency injects its very difficult to adopt the TDD concept. The methods in those mock objects will return the value to suit to the test case (controlled ways). There are 2 ways to create mock objects.

Hand coded mocks / fakes

Here we just implement the same interface into one more class and return values appropriately for different test cases. If different test cases needs the behavior in different manner we need to create many fake classes. This is not practical at all.

Mock objects using framework

The mocking framework / library can be just another .Net / Java library which can create the mock object for us. We can ask the library  "get me mock object for my interface". Then we can set rules on that returned object on how to behave when particular method is called or event fired ets... Once the mock object is set it can be injected into the code which we are testing.

I know its very hard to explain by writing. So it would be better, if we can spend some time on youtube which explains how it can be done in real life. 

Comparing mocking frameworks

We discussed about mocking library. Are there many libraries? If so which library is the best? I still didn't get the answer. We have started using Moq library to evaluate it. There are many comparisons in internet. Unfortunately none of them are recommending one library. As of my experiment with Moq, I will suggest that for simple projects. The main reason is that, Moq is the one most of the fellow developers are using :)

Links to mocking library comparisons

http://www.slideshare.net/dhelper/battle-of-the-mocking-frameworks
http://graemef.com/blog/2011/02/10/A-quick-comparison-of-some-.NET-mocking-frameworks/
http://blog.binarymist.net/2013/12/14/evaluation-of-net-mocking-libraries/
http://osherove.com/blog/2012/6/26/fakeiteasy-or-nsubstitute-which-should-i-use-for-samples-in.html

There are more concepts in unit testing such as stubbing and faking. All are related but slightly different.

Happy testing!!!