Why developers should write tests

The idea to write this post came from a discussion with one of my colleagues who were interested in how writing test can make him any better at his job.

Here is my point of view on this.

1. Tests help document behaviour of the code

There is a saying: “if you don’t write tests for your code, then your code immediately becomes a Legacy”.

Imagine that you are assigned to a project where codebase is large, there is no documentation and no one to ask about how some parts of code is expected to work.

You need to make some changes.

If you fail to correctly guess the expected behaviour of some code and after you make changes code will behave not in the way it was supposed to(even if you want it this way) it can cause errors and misbehaviour of other parts of the code that depends on old behaviour. Plus there can be external systems, applications and even end users who may depend on the old behaviour of that code.

So what problems you may get into?

– compile time errors, unlikely but possible

– runtime errors, much more luckily, especially if the programming language has dynamic typing

– incorrect results. This is most likely and tricky to become aware of. Depending on whether end-user or another system check your results somehow and provide feedback in time you may become aware of the problem soon, late or even never.

After you became aware of the incorrect problem you may have trace recursively all code that is using that code you’ve changed. With big enough codebase you might decide that writing resignation latter is better than spend the rest of your life refactoring the while project.

2. Tests help write code faster
This is counterintuitive, but true.

Imagine, that you are working on the part of the code, that to check it is working you need to do many steps on frontend to reach the place where this code is executed.

For example, thank you page after successfully placed order on ecommerce site.

To test it, you need to open the site, add one or more products to cart, go to checkout page, fill in your contact data, choose shipping method and address and only then you get to that thank you page.

This may not seem worth of effort to cover with tests, because doesn’t seem to be difficult to test.

But if you need to trough this steps 20-30 times and each iteration takes at least 2 minutes then you wasted up to hour of your time!

There two options here:

– write tests tha spin up a browser to go through these steps for you and check for expected outcome (some particular text on the thank you page)

– write a test that with give input generates that thank you page and check for expected outcome.

Both options are good and if first one is called integration test, because it involves testibg multiple parts of site, and second test is unit test, because you check single unit of code (function/method).

Probably writing both of them is a good thing to do, but they help to achieve a bit different goals, which I’ll describe next.

My point here is that both tests help save you time. Computer will run these tests faster then you, they will not make a mistake (miss click or type something wrong in the form). You save time, you have results faster, you deliver working code faster. Profit.

3. Tests can be ran as part of Continuous integration pipeline.

This way if your changes break some tests, this will not go into production. Think of tests as a snapshot of expected behavior. If it changes – you will get notified where project miss behavior happened and decide if it is good or not. Then you make changes to test and all done. No surprises, but machines check that evdrything for you, faster then you can possibly do it.

4. Tests help you write more clean and maintainable code

If you are working with some framework,like Django, you would use Object Relation Mapper(ORM) to work with data, stored in database, because that is what makes frameworks so useful – this is convenient and makes you write code faster.
It is true only partially.
When you have larger codebase it becomes harder to maintain with every new line of code.
And when you need to write tests tight coupling of business logic with ORM makes it very hard to write tests.
And many developers,that are facing this complexity just don’t write tests.
Or their tests become complex and complicated themselves making them another burden to maintain.
To make testing business logic easier, you should decouple logic from framework and its ORM.
Instead of writing code that works directly with ORM objects, write code that works with languages’ basic data objects.
Instead of writing code that calculates total order price using Customer, Order and Product models, write function that as input takes only data that it needs to produce needed result:
from Customer model – customer discount percent as Decimal or even integer
For each product – price as Decimal and available quantity as integer
All product wrap into the list
And so on.
This way your function, that calculates orders’ total cost will not depend on database.
This way you can write test for a pure function that expects several variables of basic types as arguments and returns total cost as Decimal as return value.
Such function doesn’t require a database to run and it’s result doesn’t depend on data persisted in database, this way reducing complexity.
Such function always returns same result for same set of arguments.
For such function it is very easy to write tests, because it is just a function that needs very simple test data.
And it runs faster.
You can have separate test suite for business logic and it will work faster because it doesn’t need to setup database and depend on any external system at all.
So if one day you need to only change business logic – you know where to go to make changes to code and to tests, you understand what are dependencies (ideally – none). And you have happy time maintaining this project, even after a long time without touching it.

That were my ideas that should motivate developers to write tests.

Happy coding!

Шпаргалка по оптимизации производительности сайта

Главные пункты при оптимизации скорости работы сайта.

Continue reading “Шпаргалка по оптимизации производительности сайта”

Как не надо проводить оптимизацию производительности сайта

За последние дни на просторах интернета удалось наткнуться на гору статей от “гуру” по оптимизации производительности сайтов.

Многое из того что было мной прочитано больше похоже на вредные советы оптимизатора.

Continue reading “Как не надо проводить оптимизацию производительности сайта”

Часть 3. Как маркетологи убивают производительность сайтов

В этом посте, я расскажу почему маркетологи вредны для ваших сайтов и почему их нельзя допускать к установке всякой ерунды на сайт без присмотра со стороны разработчиков или других технических специалистов, ответственных за поддержку сайта.

Continue reading “Часть 3. Как маркетологи убивают производительность сайтов”

Часть 2. Какие бывают проблемы с производительностью универсальных коробочных CMS

Многие интернет-магазины, выбирая между популярными коробочными решениями и самописными, часто выбирают первые за их простоту и обилие готовых модулей, а также поддержку и готовые интеграции со сторонними сервисами.

Эти решения отлично работают на старте, пока магазин маленький.

Тут вам и красивые интерфейсы и удобные настройки, а всякие маркетинговые задачи на базовом уровне решаются установкой дополнения из магазина модулей выбранной CMS.

Однако, у всех этих красивостей и удобств есть цена, которую приходится платить, когда магазин развивается и растёт.

Continue reading “Часть 2. Какие бывают проблемы с производительностью универсальных коробочных CMS”

Часть 1. О производительности сайтов.

Проблемы с производительностью сайта рано или поздно начинают волновать почти всех.

За последние несколько лет, я постоянно занят на многих проектах, где вопрос производительности вообще никогда не снимается и постоянно контролируется.

По этой причине, я решил описать свой опыт в нескольких постах, начиная с этого, более общего, и последующими – более подробными и специфичными.

Не существует одного подхода к решению задачи такого типа, который подошел бы всем сайтам, потому что причины разные.

Continue reading “Часть 1. О производительности сайтов.”

Набор программ для Web разработки на Android

Хочу рассказать о необычной задаче, которая встала передо мной, когда я уехал из дома на день и не взял с собой ноутбук.

Мне потребовалось быстро отреагировать на письмо от Sentry, сообщавшее об критической ошибке в продакшене.

После непродолжительных поисков я пришел к следующему набору софта, который помог мне решить задачу:

Continue reading “Набор программ для Web разработки на Android”

Проверка на наличие ip адреса в SPF с помощью Python

Мне потребовалось быстрое решение, чтобы проверять может ли определенный IP адрес, отправлять письма с заданным email-адресом.

Быстрым решением оказалось проверка TXT записи у домена, и проверка наличия IP адреса в SPF.

Для работы функции, потребуется dnspython

Вот сама функция:

Пример вызова даной функции:


Это очень топорный способ. Он учитывает только прямое вхождения ip-адреса в SPF. Таким образом, этот способ не сработает в случае, если в SPF указана подсеть, а не конкретный IP адрес. Наверняка, есть еще масса интересных моментов, которые зарыты в стандартах SPF, которые мне для быстрого решения задачи изучать не требовалось. Тем кому нужен 100% надежный способ проверки SPF записей, придется искать более надежный способ.