Brief introduction to TDD
I presented a work a small 30 min talk about Test Driven Development. Hope you'll find it useful!
Testing Spring MVC Controller with Spring Data Pages
Since version 3.2, Spring MVC offers a nice way of testing controllers using the MockMvc class. Using MockMvc, your unit tests can test Spring Controllers with an emphasis on mocking a HTTP call instead of calling a specific method on the Controller class. You can find more about the MockMvc class on the Spring Documentation.
Spring Data offers an easy way to integrate any Spring-powered application to data sources of various types (from JPA to NoSQL). Amongst one of its interesting features, there's a seamless support for pagination. Spring Data offers support to automatically paginate your queries, parsing request parameters to create a paginated request via a PageableArgumentResolver (you can find more information at the documentation page).
The documentation - however - doesn't include how to configure a PageableArgumentResolver using the page and page.size are actually parsed in your tests that use MockMvc.
In order to register the PageableArgumentResolver in your XML setup, you can use this:
[gist id="f0eeb7896754a298cad9"]
And, in order to trigger the PageableArgumentResolver in your unit tests, you need to create your MockMvc like this:
[gist id="5570813"]
The importance of a software community
One of the points of the Manifesto for Software Craftsmanship is about creating a community of professionals. Why is a community so important?
In my early career years, I didn't care too much about communities. Of course, Meetup wasn't very famous, and apart from Java User Groups and Linux Groups there weren't many opportunities for networking.
When doing our job, specially if employees of a company, we end up talking about problems we solve and technologies only with our colleagues. This gives us a slightly limited point of view, as it has always happened with every kind of society only with cultural exchange some progress happened. By finding and participating in a local community, you'll get to know people with different stories and different background - every single story shared will give you a grasp of a maybe totally different world, broadening your horizons and improving your cultural baggage. It's also a good opportunity for networking and - why not - get a better job!
I started attending the events organised by the London Software Craftsmanship Community, and I really can't recommend them more. I already met some very clever people (way better than me!) and every meetup it's a good opportunity to share knowledge and learn new things.
A professional says no
How many times, as professional software engineers, we received any kind of pressure from our managers in order to deliver software way before the actual date it can be shipped?
I need this in two days. I know you're a star, I know you can do it.
While this sentence looks very flattering (and probably it is), it hides lot more danger than expected. If we know that this needs at least one week of work, what we been asked is just impossible. However, as it has been asked by your manager, we somehow feel obliged to try it. After all, there are some actions that could be thought about...
- I won't be writing any tests, don't have time for it.
- I won't be refactoring, as I don't have time to go back on what I've already written.
- I'll work twice the number of hours per day.
- ... and some more.
The truth is, if we're thinking about these actions, we're not acting as a professional.
A professional can be defined as somebody that has a strong expertise in his field, and takes responsibility and accountability for his action. Think about a surgeon: would he try to make a surgery in half of the time because the director of the unit asked him to do so? Very unlikely. You may argue that a professional director would never ask a surgeon to do so - and you're right. A professional development manager should never ask his developers to do their job quickly - if he hired them in the first place, he should know that he hired professional people that perform at their best all the time (ok, this may not always be true, but as craftsmen we commit to perform at our best and to steadily give value).
But he asked the same. What a professional engineer then would do?
In my opinion, the first thing is being honest with ourselves, and actually think about what we are doing. Maybe the process can be improved, maybe we can make sure the team goes to lunch at the same time to avoid idle times. But sometimes this is not the case. We know that us and our team are already performing as good as we can. Still, the manager wants that. What shall we do?
We should say no.
It's obviously not easy to say to to your manager. Some manager don't take no easily as an answer, and they'll try to persuade you. After all, they know you and probably with their speech they'll find your weakest spot. Some of them - could be those with a technical background - will try to micro-manage you and not only ask you to go faster, but also how to do that.
But a professional is responsible and accountable for his actions. If a professional develops software without quality, he's not giving value. If a professional gives false hopes about a delivery, he's not talking based on facts, but on assumptions. And how many times we saw project failing due to false hopes?
Of course, we should always give our best. We should strive to improve our process, we should practice regularly to become more proficient in what we do, and we should give our employers the best quality they can ask for. This is always the first point. But - if that's already the case - saying no it's better than trying to be nice and "willing to try", giving false hopes.
Do or do not. There is no try.
P.S. This post is widely inspired by a chapter of Uncle Bob book The Clean Coder: A Code of Conduct for Professional Programmers which I'm reading at the moment. Highly recommended!