DEV Community: Elvis Pestana

No glorified hello worlds here

Elvis Pestana — Mon, 08 Jan 2018 00:28:31 +0000

In the years I have been developing software, mostly web-focused, something was always missing: Unit testing. This was due to have been in companies whose culture abhorred anything that leads to delays, even justified. Something that could not be easily justified, cost-wise, as an advantage would be throw out the window.

My experience is limited to personal projects with perfect world requirements. So, in the end, I consider myself as a beginner on unit testing.

Where to start? I can analyze — and have analyzed — projects with unit testing implemented but nothing replaces hands-on experience in real projects with users and it’s edge cases. Glorified “hello worlds” do not count.

Going back a little, I understand the advantages of unit testing. I’ve seen projects with testing implemented and the benefits it’s bringing to the table, but it’s been impossible to convince management of its importance — and even other senior developers. Maybe I’m not good at communicating the pros and cons.

Finally, the other issue that unit testing brings. Testing is like digital security. Whoever is responsible for this will always be in an ungrateful position to defend. When everything is going well, that unit testing is doing its job properly and the devs reap the benefits someone will probably say — or at least think:

Why are we wasting time with unit testing if everything is going so well? Why am I paying you?

Or even when the inevitable bugs occur:

Why are we having problems? I thought we had unit testing. Why am I paying you?

Photo by Edu Lauton on Unsplash

This is aggravating.

One time I was meeting the teams on a new company that, eventually, I joined and I remember asking “Do you do unit testing?”. The happy answer was “of course”. I was happy that I would be joining a company where I could get experience with unit testing on real-world projects. Little did I know he was referring to end-user testing. There was a team dedicated to testing entire user processes, from start to finish, to make sure everything was according to the requirements. This was good to have, but it was not unit testing. I later found that this company had an annoying habit of using industry standard names that meant something completely different inside the company. Consultants? = Glorified salesmen.

Articulating the advantages seems hard when even seasoned devs don’t want or care about unit testing. In real life, we also have to take into account company policy, personal interests — I want this project done ASAP! — which usually means getting closer to that bonus.

What are the usual pros? Let’s list them.

Finds bugs early — The sooner a bug is found, the less likely it appears on production.
Improves code quality and readability — A big advantage for big projects.
Facilitates changes giving greater confidence to the developer that his changes did not break existing functionality, therefore…
… boosts developer productivity.

Sum all of the above and you have the biggest pro since it reduces costs in the medium to long-term.

I can analyze projects with unit testing implemented but nothing replaces hands-on experience in real projects with users and it’s edge cases. Glorified “hello worlds” do not count.

What are the downsides? Let’s take a look:

Does not guarantee bug-free code. This is the obvious one, but somehow some people believe unit testing to be magical.
Time-consuming. Same as saying it costs more. Can’t release the project on time, or the project must have features cut. Managers/Clients don’t like to hear that.
Unit tests can/will have bugs. This one is down to the quality of the dev team. Have less discipline here and you will get in trouble.

It boils down to cost. A company culture that does not allow a developer to fail will not have unit testing. If you cannot count on your teammates to help, you will not have unit testing. If your company only sees you as a row on an excel spreadsheet, that means you will actually get burned with unit testing (cost) and then you will not have unit testing.

Photo by G. Crescoli on Unsplash

After reading much about unit testing the greatest advantage I see is that it makes us focus and reflect on the code written. If your code is too big or hard to read, you will most likely refactor it. In a team, this will lead to increased productivity with higher quality code bases. As a developer, I don’t need any more reasons to like unit testing.

And these debts will be paid with interest

Elvis Pestana — Mon, 01 Jan 2018 22:23:51 +0000

Something that has always bothered me, in my programmer career is building code for the short term, or the temporary hack, that will remain forever in the code base. I find it that temporary hacks are nothing more than ignorance on how, and how long, it takes to solve a specific problem.

“There’s nothing more permanent than a temporary hack.” — Kyle Simpson

Does this mean I have never done it? Of course I have, and all programmers have done it at some point in their career and, like me, will probably do it again.

So we do it on purpose, right? Well yes and no.

Yes because we are pressured by deadlines to deliver a product on time and on budget. A good developer that does this on purpose is aware of its problems, so it takes notes and/or creates an issue on the issue tracker to solve it a later time. The problem here is the “ a later time ”. If your teammates and management in your company don’t understand that it has to be done, this will, almost every time, come bite you in the ass at a later date.

How? The two most common scenarios.

Another hack will be made to compensate the shortcomings of the first one. This will pile on and a third, fourth, ad infinitum, hacks will be made to compensate the shortcomings of the previous one.
Since your name was on the commit and due to the shortcomings of said hack, you will take the blame for the time it takes to “fix” the hack — see scenario 1.

Photo by Ian Espinosa on Unsplash

This eats away at the productivity of your team and causes a sunken cost. The reasons for this cost are not obvious. The only thing that is noticed, by management, is that more money has to be spent on the project.

If someone on your team does not take notes on the hacks, this is a sign of future pain and suffering for the entire team.

Every month or so — your mileage may vary — some time should be set aside to solve these issues or risk getting drowned in them.

No , because the developer is unaware of the problems due to having low experience on how the code affects the code base. This is either inexperience as a programmer or inexperience with the code base itself. These hacks work great in the short term and give the appearance that the programmer can work in any environment, but is only leading to technical debt.

And these debts will be paid with interest.

If you scale of perfection is 1 to 10, with 10 being perfect, then always aim to 10 even though you will never get there. You will reach, hopefully, an 8 or even 9, but if you aim to the 8, you will be content with a 6 — until the day you have to maintain that code.

So my new year’s resolution will be to avoid hacks whenever possible and make sure my teammates understand the consequences of technical debt. Use mentoring, use technical tools — code reviews — or anything that is required to make sure everyone is on board.

Adventures in Laravel 5.4 land — view management

Elvis Pestana — Thu, 03 Aug 2017 19:01:02 +0000

update: This also works fine in Laravel 5.5

Recently started working with Laravel (5.4) and so far it’s been a joy to work with.

The first roadblock I encountered was on how to organize views/templates.

Page templates

I went down the simplicity path, having the following rules:

Grab the controller name, exclude the Controller part of the name, put it to lowercase. With this we have a folder that will house the templates that are used by that controller. For example: HomeController > Home > home.
Let’s assume that we create a method inside HomeController whose job is to load a generic about us page. So we create the method aboutUs and call the relevant view. What’s the name of view? Just call it about-us , which means a path /resources/views/home/about-us.blade.php.
The default controller method has a special name, __invoke, and since I did not want to have a view called invoke.blade.php I decided to just use the same name of the controller. So for now we have a folder called home with a file called home.blade.php. Based on these rules we can immediately assume, with a high degree of certainty, that the view home.blade.php is called inside HomeController::__invoke.

What about partials?

Partials are blocks of code that are reused in more than one page/view, so I needed a set of rules for creating these, so that the location where they exists makes sense and gives an ideia of how it’s used. These rules assumed you are following the previously laid out rules.

When the partial is only used among the views of a single controller, create a folder called partials inside the controller view folder. Put your partials in these. Ex: /resources/views/home/partials/example-partial.blade.php.
When the partial is used by different controllers, then put them inside a partials folder inside the views folder, on the same level as the controller views folder. Ex: /resources/views/partials/example-partial.blade.php.

Layouts

I did not see a reason to change the location of layout files (/resources/views/layouts/master.blade.php).

I’m sure there will be edge cases in which these rules cannot be applied, but I hope that these rules minimize those cases, instead of having the mess of view files that makes it hard to pinpoint what are it’s intended uses.