While deep diving into the code I very often see people struggle when testing random changing/things. There is a really simple solution for this and in this blog post, I’m going to show you "one simple trick" that will fix this problem.
Most of java web applications is built on top of the Spring Framework. Spring has pretty good support for testing and it is a mistake not to take advantage of features it offers. I’ve been developing various applications using Spring MVC for some time and I’ve noticed few patterns for testing that do work.
When I’ve got some free time I try to add new features to springmock. Lately, after adding some new stuff I realized that double definition parsing class has more than one responsibility (class parsing, naming, definition creation, etc). So I’ve decided it’s time to refactor it and split responsibilities into dedicated classes. Once I did that and tests in the shared kernel started to pass I executed mvn verify just to be sure that everything was working and it wasn’t…
Some time ago I noticed new library in our code base - Random Beans which as the name suggests is a tool developed to easily create random data and random objects for testing purposes. Unfortunately, we used it in the wrong way. Here’s how we backed up from the random test data to regain control over testing.
Page object pattern is common practice when writing automated tests using selenium. It allows to gather all possible operations on the page in one place and hide page implementation details from test case. Page object pattern can be used in the same way for angular directives, react and [put framework name here] components.
When the project gets bigger and bigger there should be more and more tests. In the perfect world, all tests should be executed really fast, but life is far from perfect and sometimes some tests are slow. When using Gradle + Spock combination we have few ways of deciding how to group tests. I’m going to explore junit @Category in combination with Spock and grade.
A few days ago I’ve stumbled upon SQL query performance issue. Git claims that I was the author so maybe that’s the reason I remember this feature. There was like 3 classes, everything was super easy and super fast all I needed to do was to let Hibernate do its thing. Then time passed, new features were requested, the model becomes more complex, the number of rows increased to ~4 million and original query became too slow.
When working on query optimization I was really happy to find that detailed tests are in place. With proper test setup I was able to test my new query to make sure all requirements are met and then quickly copy paste query to sqldeveloper run it on a test environment and verify if performance is acceptable. It wasn’t simple query and it took me some time to figure out how to make it quick and work exactly as old one. That was the time I was really glad that we invested in detailed unit tests in the beginning.
Sometimes when unit tests setup is complex we are tempted to take shortcuts and write single setup for all tests which will save as few keystrokes. In the time of writing the test it might feel like a good idea to configure complex unit test setup and reuse it in all test. This way we avoid code duplication and we create a more condensed test. This approach looks good only in the time of the writing tests. Then there is a time when unit tests must be maintained. This is the time when you usually realize that saving few keystrokes wasn’t such a good idea.