These days I am working on a multi-tenant SaaS application where we are using SQL Server as our main transactional database. Using SQL Server is fine when you run the application but for unit and integration tests you want to use an in-memory database for quick turn around, better isolation, free from any external service to be available. Last thing you want is developers to not write tests because they take too much time to run. I love the experience of running a build on a clean machine and it works without any setup or configuration.Continue reading “Running H2 in SQL Server Mode With Custom Schema Name on Connection”
Since last three months I am running a course in my office where I am teaching junior developers how to write clean and maintainable code. In my experience, you can’t make people write clean and maintainable code until you make them write automated unit tests. For the purpose of this discussion, I don’t care much whether you write test first or last. The goal should be to write quality tests.
Writing unit tests is easy but writing clean and maintainable unit tests is difficult. Over time I have realised there are properties of the test that if satisfied can help you write maintainable tests. I will not cover FIRST(Fast, Isolated, Repeatable, Self-validating, and Timely) properties as they are covered at a lot of places.
This post talks how to setup json-server to use custom id and routes. In case you don’t know, json-server allows you to run a fake HTTP server with zero coding in no time. This is a common solution to allow UI team to work while REST APIs are being developed by the backend team.
Recently, I wanted to load test one of my applications. In my previous projects, I have used Apache JMeter and Gatling. Both of them are great tools but I wanted something with ease of Apache Benchmark and web user interface. In my limited experience with Gatling and JMeter, I found that it takes time to get started with these tools. I don’t use these tools daily so there is always a learning curve for me.
My quest for an easy to use load testing tool lead me to Locust. It took me no time to get started with the tool and I was able to understand performance characteristics of my application by running a load test. I found Locust a great tool if you want to find how many request per second your system can support and how response time varies for different percentiles of requests.
Locust is an open source load testing tool written in Python. It can simulate millions of users to load test your application. It has an intuitive user interface that you can use to easily get started with it. It allows you to define custom behaviour using Python code.
Today, a colleague asked me to help him write a REST API integration test. We use Spring’s MockMvc API to test the REST API. The application uses MongoDB with Spring Data MongoDB. The application uses both MongoTemplate and Mongo based repositories for working with MongoDB. To make tests work independent of MongoDB, we mock Spring MongoDB repository interfaces.
This is a great video that explains importance of developer testing in writing robust distributed system. She talked about unit testing, integration testing, and verification language that can be used to verify a system. Unit testing is the first thing a developer can do to make sure distributed system is correct. She shared a number of anecdotes in the talk that make this talk easy to understand.
Today, I wanted to run a quick and dirty load test on one of my applications. One of the alternative that most of the developers are aware of is Apache Benchmark(or ab). For some reason, ab does not work on my mac book because of Connection reset by peer errors. So, I looked around and found Siege. It is very similar to ab and works well on mac.
To test the GET request, you would run
siege http://example.com/rest/todos/3 -c 100 -r 100
To test the POST request, you would run
siege -H 'Content-Type:application/json' "http://example.com/rest/todos POST < ./data.json" -c 10 -r 1000