I’ve been building a little home project for the past couple of months, just to experiment with programming languages and frameworks. During this time I managed to put together a simple continuous delivery pipeline, completely automated and free of charge. In the following paragraphs I’ll describe how I, in my next home project should connect those pieces of puzzles together. Maybe it will be useful for others as well. Continue reading “Notes to myself: free CD pipeline for home projects”
A few weeks back I was contacted by Packt Publishing to review a relatively newly published book: Mockito essentials. Without any further talk, let’s see:
I tried to read the book like I had never seen Mockito, or encountered any of the principles of mocking before. Under these conditions some of the chapters were very useful, others less. At many points I had the impression that examples int this book are (maybe) a bit too advanced for beginners, but not so useful for pros. This is mainly because people completely new to mocking/stubbing/faking may get lost in some rather complex pieces of code, while seasoned mockers are reading more advanced books. Continue reading “Book review: Sujoy Acharya – Mockito essentials”
Some time ago I had written a post about different ways to deal with exceptions using JUnit. It’s time to augment that post with a truly great way to achieve the same result.
Let’s look at this through an example. The task will be to implement a little method for an insurance company that registers a car to be insured by its license plate number. In Hungary, license plates follow the LLL-DDD pattern, where L stands for an uppercase letter, while D is a digit from 0 to 9. The initial requirement is simple: validate whether the input string conforms to the pattern described above; if it does, save it, else, throw an IllegalArgument exception. Continue reading “JUnit’s ExpectedException @Rule”
I often hear people claim that using string concatenations inside loops comes with a huge penalty given the performance. Usually no one knows exactly how much this penalty is; so I decided to measure it.
For this I created a very simple application, that keeps adding the string representation of the current iteration to the end of a String/StringBuilder, with the number of words increasing incrementally from 1 to a million. Actually, I am biased toward Strings, because I think they create cleaner and more readable code than StringBuilders. Having said that, let’s see how my tests performed. Here are the results:
String concat for 1 substrings: 0 millisecs.
StringBuilder concat for 1 substrings: 0 millisecs.
String concat for 10 substrings: 0 millisecs.
StringBuilder concat for 10 substrings: 0 millisecs.
String concat for 100 substrings: 1 millisecs.
StringBuilder concat for 100 substrings: 0 millisecs.
String concat for 1,000 substrings: 3 millisecs.
StringBuilder concat for 1,000 substrings: 0 millisecs.
String concat for 10,000 substrings: 179 millisecs.
StringBuilder concat for 10,000 substrings: 1 millisecs.
String concat for 100,000 substrings: 18635 millisecs.
StringBuilder concat for 100,000 substrings: 2 millisecs.
String concat for 1,000,000 substrings: 2919877 millisecs. //Well, this is more than 48 minutes… Sweet.
StringBuilder concat for 1,000,000 substrings: 24 millisecs.
In conclusion, in case of a loop with a thousand iterations makes no relevant difference with regard to runtime; above that threshold, however, it is not worth using Strings. I can hardly imagine such a huge String concat loop, though in production environments.
I have to say that the difference in the last case surprised me a lot; 48 minutes compared to 24 milliseconds, this is shocking (of course this is not a realistic example, I only included it for fun. Waiting for the app to terminate, however, was not funny at all).
That’s it, mystery solved.
There are some common patterns when it comes to unit testing. Not very hard to solve situations, however, it might take a little time to find a solution to them, especially for the first time.
In this post I’d like to share some ideas that always pop up when someone new to unit testing joins our team. These things may seem trivial after some practicing, but still. Someone might find it useful. The code examples will be in Java, the mocking -when applicable- will be done using JMock (the same principles apply to Mockito). Continue reading “Unit testing tips and tricks”
I like JUnit. I really do. It has really cool features that make my life easier when it comes to testing. I like how I can document my production code with a set of tests. I also like the clear way of separation of the test cases; that each of them have a unique, descriptive name; that they all represent a well understandable use case.
However, I hate, yes it’s true, I HATE this particular feature JUnit offers, namely parameterized test cases. Continue reading “JUnit’s parameterized test cases”