DEV Community: Elena

Unit Testing: Mocks

Elena — Wed, 18 Sep 2019 17:14:41 +0000

In this tutorial we learn how to use mocks when unit testing, why integration testing is sometimes just not enough, and how to save some trees. 🌳

Prerequisites

I assume that you already are familiar with some basic concepts of unit testing. I’ll be using Java, JUnit and Mockito, but don’t worry if you’re not familiar with them: the purpose of this tutorial is to learn to use mocking. You’ll pick up platform-specific things on the fly.

Here is a link to the repository where I have put the full source code for this article. You can download it and look at it while reading, or look at it afterwards.

Let’s go!

Our project

I borrowed this idea from a friend. Her son, 5 years old at the time, would ask her every day: "Mommy, mommy, how many days did I live today?"

The mommy would calculate and tell him: "Sweetie, you are 1868 days old today".

Next day, the son would ask again.

So she wrote him an iOS app that he could open every day and see for himself.

I thought this could be a nice idea to base this tutorial on :).

Of course, we are not going to write a full iOS app today. Our project is going to be a simple Java console app. We are going to have a small database with several registered users. When the user requests their age in days, we are going to tell them.

I am going to omit a lot of functionality in our app: there is going to be no user registration process; and our database is a small .csv file; and there is no fancy user interface, just a print to the console. I made this example as simple as possible to illustrate the mocking technique.

Here is the repository again, where all the source code is located.

Our main logic is located in this file, UserAgeCalculator.java. It contains the method calculateUserAge that is going to be the centre of our attention today.

// Calculates the user age in days.
public int calculateUserAge(int userId, Date dateTo) {
    User user = usersDatabase.getUserById(userId);
    if (user == null)
        throw new IllegalArgumentException("User doesn't exist");

    double daysDateTo = dateTo.getTime() / MILLISECONDS_IN_DAY;
    double daysUserBirthDate = user.getBirthDate().getTime() / MILLISECONDS_IN_DAY;
    return (int)(daysDateTo - daysUserBirthDate);
}

This code is pretty straightforward. First, we fetch the user from our database based on the userId. If the user wasn't found, we throw an exception, because we cannot calculate the age of someone we don't know.

After that, we calculate the difference in days between the provided date and the user birth date.

If we take a look at our database, this is what it looks like:

1,"Emma","1983-12-03"
2,"Janneke","1992-04-25"
3,"Jaap","1996-02-19"
4,"Sophie","1978-07-30"
5,"Pieter","2019-01-01"

We have several users registered, all with the user id, their name, and their birth date.

And now, to our first test.

First test

Here is our first test.

@test
public void userEmmaAge() {
    UsersDatabase usersDatabase = new UsersDatabase();
    UserAgeCalculator calculator = new UserAgeCalculator(usersDatabase);
    Date dateTo = DateHelpers.parseDate("2019-01-01");

    int resultAge = calculator.calculateUserAge(1, dateTo);

    assertEquals(12813, resultAge);
}

We have picked the user with id=1, who is called Emma, and have calculated the difference in days between the 1st of January 2019 and Emma's birthday, which is the 3rd of December 1983.

Emma is 12813 days old.

Integration test?

What we have just written is called an integration test.

We are not only testing our calculateUserAge method. We are testing several pieces of code together. In other words, our calculateUserAge depends on other code in order to work, and we have kept this dependency in our tests.

What does it depend on?

Actually, it depends on the implementation of the UsersDatabase. calculateUserAge is calling the UsersDatabase.getUserById method, which opens the database, reads the user by id, and returns this user to the caller.

So, in short, our unit test has a dependency on the database.

Why is this bad?

This is not necessarily bad.

Integration tests are a great tool to ensure that your whole app is working well together. When you have several pieces of code, covered well with unit tests, but you haven't tested them working together, there is a chance that you missed a bug. There might be a problem with the pieces working together, and you might miss it if you only test them individually.

If we were working on a real app here, we could decide to have a bunch of unit tests for checking the calculation logic and a couple of integration tests to ensure that the whole app works well.

Integration tests are usually more expensive to run. When your test accesses a database, pushes some data into a queue, calls another service via network and processes the response data, this takes time. An integration test will run slower than a unit test.

Along with that, you might need some protection measures to ensure your integration test doesn't mess with the real production data.

Why is using the production data bad?

Again, it is not necessarily bad in itself. However, there are some complexities this adds.

Tests writing in the database

One problem occurs if your test writes some data to a database. If you run this test, there will be new entries in the database. You will have to take measures to ensure you don't run this on the production database.

Tests reading from the database

It is a bit easier with reading the data. When reading the data, you don't mess with it, you just read it, right? Your production stays safe, right?

While this might be true, there are some problems with reading still.

Missing cases

We can list a couple of problems with integration tests that will not let us test our app fully and extensively.

Data stability

One problem is that production data is sometimes not stable. In our age-calculating app, new users are registered every day, and some users leave the app as well.

What happens if Emma deletes her account?

You can simulate that by deleting Emma from our little database and running the test.

Yes, our test will start failing. Since the user with id=1 will not be found, the calculateUserAge method will throw an exception, and this is definitely not what we expect.

Data richness

The production data for our new app is small. Many cases are not present in our database (just yet).

If we think about cases, like we discussed in this article, we might find that we want to test much more than just our 5 users offer.

For example, right now we don't have a user who is going to be born in the future. But it is possible that an expecting parent might register in our app and count the days before the baby arrives, according to the doctors' predictions. I would like to test this case just to make sure that when this happens in production, our app is prepared and displays the correct number: i.e., -10 days.

Another case would be when we want to calculate the age of a user not present in the database. Remember, our calculateUserAge method throws an exception in this case.

For this, we need to fetch a user in the test whose id is not present in the database. say, we have 5 users right now, with ids from 1 to 5, how about we use 42 for a non-existing user?

@test
public void nonExistingUser() {
    UsersDatabase usersDatabase = new UsersDatabase();
    UserAgeCalculator calculator = new UserAgeCalculator(usersDatabase);

    Date dateTo = DateHelpers.parseDate("2019-09-12");

    assertThrows(IllegalArgumentException.class, () -> {
        int resultAge = calculator.calculateUserAge(42, dateTo);
    });
}

Of course, if our app is popular, we'll reach 42 users in no time. This test will start to fail because it won't be throwing an exception anymore.

Environment stability

When the connection to our database fails, we might want to display a message to the user: "Sorry, something went wrong, please try again in a moment".

Naturally, we might want to test that.

However, it might just so happen that our connection is rather stable, and the database doesn't go down while you're running your tests.

This means that a test expecting the database to fail will most likely never pass.

Imagine a different app that compiles a report and sends it to a printer. You wouldn't want to waste paper every time you want to run the tests, would you? In cases like this one, "cutting off" the real environment helps to simplify the app and concentrate on its logic, and also save some trees. 🌳

Mocking

In order to overcome these problems, we will turn this test into a true unit test. We will cut off the dependency on the database and will replace it with our own "database", a fake one, the one that we will make individually for each test.

The code will not know the database is fake and will work as it should. But we will! And this makes us powerful.

Let us see how it's done.

Take a look at this new test suite.

@test
public void userBabyAge() {
    UsersDatabase usersDatabase = Mockito.mock(UsersDatabase.class);
    int userId = 42;
    User user = new User(userId, "Baby", DateHelpers.parseDate("2019-09-01"));
    Mockito.when(usersDatabase.getUserById(userId)).thenReturn(user);

    Date dateTo = DateHelpers.parseDate("2019-09-12");

    UserAgeCalculator calculator = new UserAgeCalculator(usersDatabase);

    int resultAge = calculator.calculateUserAge(userId, dateTo);

    assertEquals(11, resultAge);
}

Look at how we create the UsersDatabase instance. Here is what we did before:

UsersDatabase usersDatabase = new UsersDatabase();

And here's what we are doing now:

UsersDatabase usersDatabase = Mockito.mock(UsersDatabase.class);

We have just created a pretend database, a completely fake one, which will behave as we wish, and will only exist for our test.

After that, we create a user:

User user = new User(userId, "Baby", DateHelpers.parseDate("2019-09-01"));

We have just created a user which does not exist in our database. A completely pretend user, not real.

Then, we make our pretend database work with our fake user:

Mockito.when(usersDatabase.getUserById(userId)).thenReturn(user);

After that, we create our calculator and calculate the age of this very user with userId = 42.

See what we're doing here? Only this imaginary user "exists" in our pretend "database", and we made them only for this test. The test doesn't access the real UsersDatabase now. We have all the power!

This technique is called mocking, and this fake database is called a mock. By adding this mock and replacing the real database with it, we have made our test a pure unit test. This is really powerful because now we can test all scenarios that we couldn't before.

How about a non-existing user? How about a user from the future? Everything is possible now.

What are other things mocks are useful for?

Imagine we would not return the age of the user as a return value, but instead would print it on paper.

This would be very difficult to test. Of course, you don't want to waste paper, but the larger problem is that your test would have to find the printer, pull the paper out of it, photograph the text, apply some cool text recognition techniques to see what is being printed, and compare the recognised text with the expected value.

This sounds pretty cool, but it is so difficult to implement. Is there a way to do it easier?

Yes, mocking helps with this as well. If you would mock the printer instance, you could ensure that Printer.print() was called exactly once with specific arguments.

Mocking frameworks have a number of useful possibilities. You can check how many times a method was called. You can see what arguments were passed each time and then compare only the ones that are needed. You can mock several consecutive calls to one method and make them return different values. You can make every second call throw an exception. I am not sure if this would be useful, but hey, it might be. Take a look at the documentation of your favourite mocking framework to see the full list.

Summary

We have briefly discussed the difference between unit tests and integration tests. Sometimes, unit tests are more desirable than integration tests. Along with that, writing, supporting and running unit tests is easier and cheaper than integration tests.

We have learned to apply mocking in order to isolate our code from external dependencies and write pure unit tests.

Mocking lets us explore more scenarios that were not possible when using "real" data, and our tests are more stable because we control the environment now.

Unit Testing: Mocks

Elena — Thu, 12 Sep 2019 14:32:48 +0000

This post was originally published in my blog smartpuffin.com.

In this tutorial we learn how to use mocks when unit testing, why integration testing is sometimes just not enough, and how to save some trees. 🌳

Prerequisites

Here is a link to the repository where I have put the full source code for this article. You can download it and look at it while reading, or look at it afterwards.

Let’s go!

Our project

I borrowed this idea from a friend. Her son, 5 years old at the time, would ask her every day: "Mommy, mommy, how many days did I live today?"

The mommy would calculate and tell him: "Sweetie, you are 1868 days old today".

Next day, the son would ask again.

So she wrote him an iOS app that he could open every day and see for himself.

I thought this could be a nice idea to base this tutorial on :).

Here is the repository again, where all the source code is located.

Our main logic is located in this file, UserAgeCalculator.java. It contains the method calculateUserAge that is going to be the centre of our attention today.

// Calculates the user age in days.
public int calculateUserAge(int userId, Date dateTo) {
    User user = usersDatabase.getUserById(userId);
    if (user == null)
        throw new IllegalArgumentException("User doesn't exist");

    double daysDateTo = dateTo.getTime() / MILLISECONDS_IN_DAY;
    double daysUserBirthDate = user.getBirthDate().getTime() / MILLISECONDS_IN_DAY;
    return (int)(daysDateTo - daysUserBirthDate);
}

After that, we calculate the difference in days between the provided date and the user birth date.

If we take a look at our database, this is what it looks like:

1,"Emma","1983-12-03"
2,"Janneke","1992-04-25"
3,"Jaap","1996-02-19"
4,"Sophie","1978-07-30"
5,"Pieter","2019-01-01"

We have several users registered, all with the user id, their name, and their birth date.

And now, to our first test.

First test

Here is our first test.

@test
public void userEmmaAge() {
    UsersDatabase usersDatabase = new UsersDatabase();
    UserAgeCalculator calculator = new UserAgeCalculator(usersDatabase);
    Date dateTo = DateHelpers.parseDate("2019-01-01");

    int resultAge = calculator.calculateUserAge(1, dateTo);

    assertEquals(12813, resultAge);
}

We have picked the user with id=1, who is called Emma, and have calculated the difference in days between the 1st of January 2019 and Emma's birthday, which is the 3rd of December 1983.

Emma is 12813 days old.

Integration test?

What we have just written is called an integration test.

What does it depend on?

So, in short, our unit test has a dependency on the database.

Why is this bad?

This is not necessarily bad.

If we were working on a real app here, we could decide to have a bunch of unit tests for checking the calculation logic and a couple of integration tests to ensure that the whole app works well.

Along with that, you might need some protection measures to ensure your integration test doesn't mess with the real production data.

Why is using the production data bad?

Again, it is not necessarily bad in itself. However, there are some complexities this adds.

Tests writing in the database

Tests reading from the database

It is a bit easier with reading the data. When reading the data, you don't mess with it, you just read it, right? Your production stays safe, right?

While this might be true, there are some problems with reading still.

Missing cases

We can list a couple of problems with integration tests that will not let us test our app fully and extensively.

Data stability

One problem is that production data is sometimes not stable. In our age-calculating app, new users are registered every day, and some users leave the app as well.

What happens if Emma deletes her account?

You can simulate that by deleting Emma from our little database and running the test.

Yes, our test will start failing. Since the user with id=1 will not be found, the calculateUserAge method will throw an exception, and this is definitely not what we expect.

Data richness

The production data for our new app is small. Many cases are not present in our database (just yet).

If we think about cases, like we discussed in this article, we might find that we want to test much more than just our 5 users offer.

Another case would be when we want to calculate the age of a user not present in the database. Remember, our calculateUserAge method throws an exception in this case.

For this, we need to fetch a user in the test whose id is not present in the database. say, we have 5 users right now, with ids from 1 to 5, how about we use 42 for a non-existing user?

@test
public void nonExistingUser() {
    UsersDatabase usersDatabase = new UsersDatabase();
    UserAgeCalculator calculator = new UserAgeCalculator(usersDatabase);

    Date dateTo = DateHelpers.parseDate("2019-09-12");

    assertThrows(IllegalArgumentException.class, () -> {
        int resultAge = calculator.calculateUserAge(42, dateTo);
    });
}

Of course, if our app is popular, we'll reach 42 users in no time. This test will start to fail because it won't be throwing an exception anymore.

Environment stability

When the connection to our database fails, we might want to display a message to the user: "Sorry, something went wrong, please try again in a moment".

Naturally, we might want to test that.

However, it might just so happen that our connection is rather stable, and the database doesn't go down while you're running your tests.

This means that a test expecting the database to fail will most likely never pass.

Mocking

The code will not know the database is fake and will work as it should. But we will! And this makes us powerful.

Let us see how it's done.

Take a look at this new test suite.

@test
public void userBabyAge() {
    UsersDatabase usersDatabase = Mockito.mock(UsersDatabase.class);
    int userId = 42;
    User user = new User(userId, "Baby", DateHelpers.parseDate("2019-09-01"));
    Mockito.when(usersDatabase.getUserById(userId)).thenReturn(user);

    Date dateTo = DateHelpers.parseDate("2019-09-12");

    UserAgeCalculator calculator = new UserAgeCalculator(usersDatabase);

    int resultAge = calculator.calculateUserAge(userId, dateTo);

    assertEquals(11, resultAge);
}

Look at how we create the UsersDatabase instance. Here is what we did before:

UsersDatabase usersDatabase = new UsersDatabase();

And here's what we are doing now:

UsersDatabase usersDatabase = Mockito.mock(UsersDatabase.class);

We have just created a pretend database, a completely fake one, which will behave as we wish, and will only exist for our test.

After that, we create a user:

User user = new User(userId, "Baby", DateHelpers.parseDate("2019-09-01"));

We have just created a user which does not exist in our database. A completely pretend user, not real.

Then, we make our pretend database work with our fake user:

Mockito.when(usersDatabase.getUserById(userId)).thenReturn(user);

After that, we create our calculator and calculate the age of this very user with userId = 42.

How about a non-existing user? How about a user from the future? Everything is possible now.

What are other things mocks are useful for?

Imagine we would not return the age of the user as a return value, but instead would print it on paper.

This sounds pretty cool, but it is so difficult to implement. Is there a way to do it easier?

Yes, mocking helps with this as well. If you would mock the printer instance, you could ensure that Printer.print() was called exactly once with specific arguments.

Summary

We have learned to apply mocking in order to isolate our code from external dependencies and write pure unit tests.

Mocking lets us explore more scenarios that were not possible when using "real" data, and our tests are more stable because we control the environment now.

Writing Good Unit Tests: A Step By Step Tutorial

Elena — Wed, 11 Sep 2019 16:52:38 +0000

This post was originally published in my blog smartpuffin.com.

Let's imagine we just wrote a method calculating distance between two points on our planet. And let's imagine we want to test it as well as possible. How do we come up with test cases? And what exactly do we need to test?

Bonus: learn a surprising fact about the Fiji islands. 🇫🇯

Prerequisites

I assume you are already familiar with the concepts of unit testing. I'll be using Java and JUnit, but don't worry if you're not familiar with them: the purpose of this tutorial is to learn to write fuller test suites. You'll pick up platform-specific things on the fly.

Here is a link to the repository where I have put the full source code for this post. You can download it and look at it while reading, or look at it afterwards.

And here is my previous article on unit testing topic explaining best practices in unit testing more widely.

Let's go!

Positive cases

Let's start with thinking about our method as of a black box.

We have this API:

// Returns distance in meters using haversine formula
double getDistance(double latitude1, double longitude1, double latitude2, double longitude2);

What can we test?

Putting yourself in a testing mindset

You need to switch from being a developer to being a tester now. This means you have to stop trusting yourself. You can't know your code is working if you didn't test it!

If you tested it manually, you don't know if it's going to work next time someone makes a change - in your code or close to it.

Moreover, you can be sure that whatever code you build on top of this well-tested piece, you have one less problem to worry about.

The feeling of security you have when your code is well-tested is incredible. You can refactor freely and develop new features further - and be sure your old code is not going to break.

Promise yourself a treat if you find a bug. But do be careful: too many cookies are bad for your health.

First test

Okay, we are ready to test! What should we test first?

The very first thing that comes to mind, is:

Calculate the distance between two points and compare with the true real number calculated manually. If they match, all is well!

And this is a great testing strategy. Let's write some tests for that.

I'll pick a couple of points: one in the very north of the Netherlands, one - in the very south. Practically, I want to measure the country from top to bottom.

I clicked at a couple of points on the map and got this:

Point 1: latitude = 53.478612, longitude = 6.250578.
Point 2: latitude = 50.752342, longitude = 5.916981.

I have used an external website to calculate the distance and got 304001.021046 meters. That means the Netherlands are 304km long!

Now, how do we use this?

Thinking about domain area

We need to think about domain area-specific things. Not all of them are obvious from the code: some of them depend on the area, some - on the future plans.

In our example, the returned distance is in meters, and it's a double.

We know that a double is prone to rounding errors. Moreover, we know that the method used in this calculation - the haversine formula - is somewhat imprecise for our oh-so-complex planet. It is enough for our application now, but perhaps, we'll want to replace it with higher-precision calculation.

All this makes us think that we should compare our calculated value with our expected value with some precision.

Let's pick some value that is good for our domain area. To do that, we can remember about our domain area and requirements again. Would 1mm be fine? Probably it would.

And here is our first test!

double Precision = 0.001; // We are comparing calculated distance using 1mm precision
...
@test
void distanceTheNetherlandsNorthToSouth() {
    double distance = GeometryHelpers.getDistance(53.478612, 6.250578, 50.752342, 5.916981);
    assertEquals(304001.0210, distance, Precision);
}

Let's run this test and make sure it passes. Yay!

More tests

We calculated the distance across the Netherlands. But of course, it is a nice idea to double-check and to triple-check.

Your tests should vary - this helps you cast a wider net for these pesky bugs!

Let's find some more nice points. How about we learn how wide Australia is?

@test
void distanceAustraliaWestToEast() {
    double distance = GeometryHelpers.getDistance(-23.939607, 113.585605, -28.293166, 153.718989);
    assertEquals(4018083.0398, distance, Precision);
}

Or how far is it from Capetown to Johannesburg?

@test
void distanceFromCapetownToJohannesburg() {
    double distance = GeometryHelpers.getDistance(-33.926510, 18.364603,-26.208450, 28.040572);
    assertEquals(1265065.6094, distance, Precision);
}

Now that we think about that: are we sure that the distance doesn't depend on the direction in which we are calculating? Let's test that as well!

@test
void distanceIsTheSameIfMeasuredInBothDirections() {
    // testing that distance is the same in whatever direction we measure
    double distanceDirection1 = GeometryHelpers.getDistance(-33.926510, 18.364603,-26.208450, 28.040572);
    double distanceDirection2 = GeometryHelpers.getDistance(-26.208450, 28.040572, -33.926510, 18.364603);
    assertEquals(1265065.6094, distanceDirection1, Precision);
    assertEquals(1265065.6094, distanceDirection2, Precision);
}

Corner cases

Great, we have covered some base cases - the main functionality of the method seems to work.

We can have a cookie now - for going half-way through. 🍪

Now, let's stretch our code to the limit!

Thinking about the domain area helps again.

Our planet is rather a ball than a plane. This means that there is a place where latitude goes from 180 to -180, leaving a "seam" where we should be careful. Math around this area often contains mistakes. Does our code handle this well?

A good idea would be to write a test for it, don't you think?

Working with geo? Always Check With Fiji!

@test
void distanceAround180thMeridianFiji() {
    double distance = GeometryHelpers.getDistance(-17.947826, 177.221232, -16.603513, -179.779055);
    assertEquals(351826.7740, distance, Precision);
}

Upon further thinking, I discovered one more tricky case - distance between two points which have the same latitude; but the longitude is 180 in one point and -180 in the other.

double distance = GeometryHelpers.getDistance(20, -180, 20, 180);
// Question to you, my reader: what is this distance?

Okay, we're done with that weird 180th meridian. We are sure about the 0th meridian though... right? Right? Let's test it too.

@test
void distanceAround0thMeridianLondon() {
    double distance = GeometryHelpers.getDistance(51.512722, -0.288552, 51.516100, 0.068025);
    assertEquals(24677.4562, distance, Precision);
}

What other cases can we come up with? I thought a bit and listed these:

How about poles? Let's calculate a couple of distances in the Arctic and Antarctica.
How about from one pole to another?
How about the max distance on the planet?
How about a really small distance?
If both points are absolutely the same, are we getting 0 m distance?

I'm not adding all these tests here, as it would take too much space. You can find them in the repo. You get the point. Try to think creatively. It's a game of coming up with as many ideas as possible. And don't be afraid with coming up with "too many ideas". The code is never "tested too well".

What's inside

At this point, it can also help to peek inside the code. Do you have the full coverage? Maybe there are some "ifs" and "elses" in the code that may give you a hint? Do google "haversine formula" and look at its limitations. We already know about precision. Is there something else that could break? Is there some combination of arguments which can make the code return an invalid value? Brainstorm about it.

Negative cases

Negative cases are cases when the method is supposed to refuse to do its job. It is a controlled failure! Again, we should remember about the domain area. Latitude and longitude are special values. Latitude is supposed to be defined in exactly [-90, 90] degrees range. Longitude - in [-180, 180] range. This means that in case when we passed an invalid value, our method throws an exception. Let's add some tests for that!

@test
void invalidLatitude1TooMuch() {
    assertThrows(IllegalArgumentException.class, () -> {
        GeometryHelpers.getDistance(666, 0, 0, 0);
    });
}

@test
void invalidLatitude1TooLittle() {
    assertThrows(IllegalArgumentException.class, () -> {
        GeometryHelpers.getDistance(-666, 0, 0, 0);
    });
}

Same tests we'll add for latitude2, and for both longitude parameters.

We're writing Java here, and the double parameters can't be null. But if you're using a language where they can, test for it!

If you're using a dynamically typed language, and you can pass a string instead of the number, test for it!

Side point: dynamically typed languages will require some more extensive testing than statically typed ones. With the latter, compiler takes care of many things. With the former, it's all in your hands.

Wrapping up

You can see and download the source code for this tutorial here. Look at it and try to come up with some more useful testing scenarios.

ice-lenor / ExampleUnitTests

ExampleUnitTests

This is the source code for the tutorial about writing good unit-test suites.

Tutorial

See the tutorial here:

http://smartpuffin.com/unit-tests-tutorial/

What to do with this

Open the tutorial.
Open GeometryHelpers.java.
Open GeometryHelpersTest1.java. Review the test structure. Run the test.
Open GeometryHelpersTest2.java.
Compare the first test in GeometryHelpersTest1.java with the first test in GeometryHelpersTest2.java. See how even the smallest pieces of domain area knowledge are important?
Think about what else you could test. I'm sure there is something I missed!
Apply the best practices in your own project.
Like the tutorial? Share, like, subscribe, say thanks. I'll be happy to know it!

How to run tests

I run this with Intellij IDEA and Java 1.8+.

Download the source code.
Open the folder with the code in Intellij IDEA.
Open the file GeometryHelpersTest1.java. You'll see green "Run test" buttons next to line numbers. Press the one next…

View on GitHub

Here's some followup reading to learn about best practices in unit testing.

Unit testing: best practices

Elena ・ Mar 21 '18

#unittesting #codequality #testing

For your own projects, select the part that would benefit from testing the most - and try to cover it with tests. Think creatively! Make it a challenge, a competition with yourself!

Unit testing is fun!

How To Switch To Software Industry

Elena — Thu, 15 Aug 2019 11:49:53 +0000

I am often being asked by friends and acquaintances: how do I switch from my current profession to software development?

After the third question I decided to write it down.

All of the following are my personal recommendations, my personal advice. Of course, everyone is different, learning at different speed, motivated by different things. This is how I see things and what I recommend my friends.

1. Welcome!

First of all: welcome to our field. We need more people like you here.

Many people nowadays switch their careers, and it is awesome. When you have worked in different fields, you will have a wide range of skills that will come useful.

For instance, if you did marketing and sales, you know how to talk with people. You will be able to easily to persuade your colleagues to go with your approach or your users to try your product. This is an invaluable skill in software engineering.

Or, if you were a QA specialist, you already know a lot about common problems in software development. You are quality-oriented and attentive to details. Perhaps, you already know how to code. These skills are going to prove extremely useful.

Whatever career you were pursuing before, you know how to learn, how to work hard, you are determined and goal-oriented.

If you really want to and if the circumstances allow you to, do not be afraid to switch. You will definitely succeed.

2. What area to choose?

Machine learning? Web development? Android apps? Videogames? There are so many different things, and all of them sound so cool.

Concentrate on one thing

I strongly recommend picking one area and concentrating on it. When you mastered it, you can slowly expand into related areas.

For example, let's say you always wanted to build websites. It's great! Start with HTML, CSS, Javascript, and at this point you are basically ready to land your dream job or to build your dream website.

When you have mastered these skills, you can expand further. One way would be to learn backend technologies and skills: a backend language, a database, networking, etc. Another way – to pick up design skills.

Most likely, you have limited time. (More about this later.) Because of that, you need to pick an industry realistically. It is more realistic to expect to learn only frontend within 6 months than to learn frontend, backend and machine learning skills.

Along with that, in my opinion, if you start to learn many new things at once, it is going to be very difficult to manage. Brain needs to go step by step.

It will also take you more time to learn many technologies to the "production-ready" state, and you surely want to start your new career sooner?

Go visual

Another advice I usually give is to start with something visual. I started learning by building windows applications with Delphi. Simply painting buttons green brought me a lot of joy. (Ah, good times.) I could see my results, I could proudly show my tiny green-buttoned app to other people, and this encouraged me to learn more. It was fun.

If I were to start with sorting numbers in memory, I am not sure I would be so enchanted by it.

If you build an app or a website, you will immediately see the results on your screen. This motivates a lot.

Moreover, sharing your achievements with people is fun! It is easy to show a website to any other person in the world, but to show off your amazing new ML model you need someone who understands what it means. Or, you know, you need to build a website for it:).

Showing visual results in your CV or on your interview also helps with the job search. The employer can immediately see what your skills are.

What do you like?

If there is an area that you really like, go for it!

If you always wanted to make (insert your thing here), start with it. Your motivation is the most important driver on your road to success 🚗.

For example, if you always wanted to make iOS apps, then start learning that. There is, of course, the possibility of starting to learn how to build desktop apps, then Android apps, then slowly expand to iOS, but if your heart yearns to enrich the Apple ecosystem – why shouldn't you?

What do you already know?

There is a chance you learned some Python in the university, or perhaps built a couple of pages with HTML+CSS. Great! You won't be starting completely from scratch. Perhaps, it's a good idea to build on these skills. Freshen them up with an online course and see if this helps.

What is the demand on the market?

What do employers want at the moment?

If you go for an obscure technology, there is a chance the market for it is so small, there are no positions for you in your city.

Try to estimate: how useful your skill will be when you're looking for a job.

3. Start with fundamentals or practical skills?

There are two different approaches.

The first one – the oldest, the most traditional approach – is to start with fundamentals. You learn assembler, algorithms, math, C, low-level networking, how transistors work and what electrons are. This is very interesting. This takes time. Not all of these skills you are going to apply in your every day job. You will gain a deep understanding of the whole industry and around it, and it costs time.

The second approach is to learn very practical skills first. It seems rather modern, as bootcamps are just starting to take over the world. But at the same time, it is as old as humanity. Mothers have been passing their knitting and wood carving skills to her daughters and sons for hundreds and thousands of years.

In this second approach, you would start with learning HtML and you would build a web-page immediately. You don't know yet how exactly browsers work and how the data is stored on the backend side, but you have a visible result.

The first approach is usually what you do in a university or in college. The second approach is more popular in bootcamps and in self-learning.

If I were to change the industry right now, I would go for the second approach. I would be willing to see the results right away and to start as soon as possible, and I would be eager to learn the rest on the fly.

I would be more cautious to spend 2-3 years on learning everything from the beginning. It would be difficult for me to justify setting so much time aside, with the result so far ahead in the future.

Besides, since you are switching from another profession, you probably already know a lot of fundamentals which are the same across industries. If you have already studied math for your previous engineering job, you don't need to take the same course again.

Some bootcamps claim that after several months of studying a person will be able to find a new job. Some of them even delay the payment until the student finds a new job with a certain salary level. This seems like a risky approach, but these bootcamps are rather successful. I absolutely believe that a dedicated person is able to do just that: learn practical skills in several months and find a new job.

4. Goals and restrictions

We all are busy people and have a lot of commitments. Jobs, children, hobbies, friends, budget planning, mortgage, renovations.

That's why it's important to set some limitations. (And life can set some limitations for you.)

Try to answer this question:

What is your specific goal?

It doesn't have to be a lifetime goal to run a startup with 10 000 employees or to build a rocket for the European Space Agency. Keep it mid-term: say, 6 months or 1 year.

So, what do you want to achieve within this time limit? And what can you achieve?

A reasonable goal would be: "within 1 year I can learn one stack of technologies to a decent level and find a job". Or, perhaps: "within 6 months I will learn how to build Android apps and will build this app I have an idea for".

Next question you have to ask yourself:

How much time can you dedicate?

Do you have weekends and evenings at your disposal? Do you only have 2 evenings a week? Maybe you can dedicate your full time to this?

Of course, it depends on your engagements and your current job.

You can balance and negotiate your limits. Maybe you have to push your end date by a couple of months or find a way to spend more time on your learning during the week.

Set a goal realistically. It is only demotivating to expect to finish everything within 2 weeks and then fail.

This exercise also might help you with picking an industry. If you want to learn machine learning but only have 6 months and 2 evenings a week, perhaps you should start with something simpler.

5. Find a mentor

A mentor is someone who would oversee your progress and help you with learning. It is helpful if your mentor is someone specialising in the same technology you are learning about, but not strictly necessary.

They will gently guide your progress, give you materials to learn, assess what your strengths are and what skills you need to pick up next.

If they're knowledgeable in your specific area, you can also ask your mentor questions about specific problems you're encountering.

A mentor is especially helpful if you're learning on your own. In a bootcamp or in a university you'll have a lot of people around you ready to teach and help, but if you're following online courses, you might feel lonely and lost sometimes.

A mentor can introduce you to other people doing similar jobs, or perhaps even refer you to a position in their company.

An unexpected plus of a mentor is that you would feel responsible to work in order to not let the mentor down. They will hold you responsible, in a way – even if they're the nicest person in the world. They will make you feel accountable.

Imagine that you met with your mentor, they have sent you an article to read, and next time you meet them, you haven't read the article? Surely, you don't want to let them down this way?

6. Consider downsides

There are, of course, downsides of learning a lot and switching a job.

One problem is that learning takes a lot of time and dedication. It is basically a second job. It is easy to not spend your evenings on this new job and watch nature documentaries instead because you are tired.

Consider what level of career you are on now. If you are to switch your career, you are likely to start from a junior position. This might provide you with less income for a while.

Software industry is growing. It is dynamic. This means there is a certain level of chaos. New technologies come and go, companies open and close overnight, and what was on the rise yesterday is forgotten today. Because of that, you will have to learn a lot every day, even after you have seemingly "finished" your studies and have found a job. You will not be able to "relax" into a routine.

Software industry might feel toxic. Despite the fact it is a relatively new area of human knowledge, and it is full of smart educated people, we have already made a mess out of it. Overtime hustle, many rounds of intentionally stressful interviews, and gatekeeping are very common issues. The gender proportion in the industry also leaves me wishing for more equality (based on different reports, only 10-30% of tech positions are held by women in 2019). As a result, people burn out, become sick, leave the industry. Unfortunately, I don't have a specific advice on how to avoid or overcome these problems. It is something our whole industry should become better at, all together. I just want to warn you about these problems in your new profession. It is not all roses and ponies 🦄.
I am not trying to say that the tech industry is the worst. I am sure many other professions suffer from similar problems. On the other hand, the tech industry is wonderful, interesting, lets you make something with your own hands, has many nice and inspiring people.

Good luck with your choice, and I hope to see you as my colleague soon!

Nevertheless, Elena Coded

Elena — Thu, 07 Mar 2019 16:12:37 +0000

I wrote the first #shecoded post in 2018, and I liked the opportunity to share, so I'm sharing again.

I continued to code in 2019 because...

2019 is my 11th year of coding professionally.
During these years, I did a lot! I built large systems from scratch, and small ones, done bugfixing in huge codebases almost my age, collected user requirements, argued with users:), wrote automated tests, didn't test enough and broke things, added monitoring, broke monitoring, mentored colleagues, grew junior developers, advocated for minorities in tech, led training, led teams, led projects,
became a manager, then a developer again, then a manager, than a developer, built products alone and in a team, built and launched my own projects and charged for them.

I worked on products which a small number of users uses 24/7 and which millions of users use every day. Enterprise, e-commerce, SaaS and smartphone apps.

I continue to code because I like how I can create a product out of nothing. It costs me almost nothing, and I can do it alone, but hundreds, thousands, millions of people will find it useful.

I deserve credit for...

Writing useful articles about software development 👩‍💻
Running in-person trainings for my colleagues and helping to share the knowledge 👩‍🏫
Launching 2 own projects 🥳

I hope to see my tech community...

To become diverse and inclusive.

Geo Crash Course

Elena — Fri, 11 Jan 2019 09:03:36 +0000

What do you need to know when starting in Geo as a developer? Read on to know!

For a very long time I planned to write this guide on starting in Geo. In this guide, I will:

Tell you that Earth is not flat (SHOCK!) and why that's very inconvenient;
Define common terms (What's projection? There's also a coordinate system?.. OGC, OSM, WKT, WGS, ESPG?);
Teach you All Things You Need To Know™ to become a geo-developer and build things for Geo or using Geo;
Explain popular caveats - Dos and Don'ts - when working with Geo;
Give you an overview of geo-technologies, industry standards, databases, libraries;
Give you references for further reading.

I ran this workshop for my colleagues who are interested in Geo, and it was a great success! I hope you enjoy it as well.

Good luck with your journey around the globe!

How I Deal With Bad User Feedback

Elena — Mon, 17 Dec 2018 17:41:16 +0000

This post was originally published in my blog smartpuffin.com.

We all know this feeling. You spend your precious time to develop an awesome project, polish it to perfection, and carefully roll it out for your users.

And then they tell you:

★☆☆☆☆ BOO! Worst app EVER! Do NoT UsE!!!11

My WordCloud app has 1.7M users and 5K reviews on Google Play. The average review score is 4.5★. This means that many users love the app, but some don't.

I used to dread bad reviews! First ones were a nightmare. I was scared to read all reviews in fear that there is a negative one. Upon seeing one, I used to spend days feeling miserable and unfairly judged.

But I couldn't feel miserable forever. So after some time developed these rules and I started to follow them.

Constructive bad reviews

When the review is constructive, I usually reply.

If they couldn't understand how to use a particular feature, I write an instruction for them.

It also helps other users who might experience the same problem. This is valuable feedback — maybe I should reconsider the feature or its UI if it is unclear for many people.

If they expected a feature that's not present, I explain it and promise to consider it in the future.

This doesn't mean I'll add the said feature. Perhaps, it doesn't fit my product vision, or maybe there are technical constraints. So I don't promise to implement — I just promise to consider. Still, this is valuable feedback, and sometimes these ideas are really good — even though they make me sad for a little while.

Destructive reviews

If the review is like "worst app ever!!111", I don't reply. There is no point in replying. I learned to grow thick skin against these types of reviews. Some people just want to be negative on the internet. It doesn't say anything about you, your product, or the quality of it. Some percentage of reviews will be like that anyways, for any app, however great it is.

Reviews complaining about how stuff isn't free

Sometimes the only complaint is that some features in the app are paid.

Or like this:

To such reviews, I usually don't reply. I can't help the user in any way. This just means my product is not for them.

I only posted an answer once, and here it is:

Positive reviews

It warms my heart when people find my work useful!

To such reviews on Google Play, I usually reply "thank you" or nothing at all, since there are sometimes too many reviews — but I really do appreciate them.

I reply to all emails though. An email means that a person took time to message me personally, and I appreciate that.

I even got a physical present from a happy user once! That made me sooo happy!..

"This is not about my app" reviews

And now, a funny story. I sometimes get bad reviews that are about OTHER apps :).

There are a bunch of "impostor" apps that mimic mine. They have the same name and a similar UI, but are filled with lots of annoying ads and often don't work. So people download them, try to use, fail, get angry, and type the reviews for my app because it's on top in the Google Play when you search for "Word Cloud".

I even got a couple of emails from people using these impostor apps on OTHER PLATFORMS — such as iOS, while my app is Android-only. (So far.)

There is nothing I can do against these reviews, or these apps for that matter — Google and Apple don't help much in fighting them. I find consolation in the thought that my app is so great it's worth copying :).

Writing Good Unit Tests: A Step By Step Tutorial

Elena — Wed, 21 Nov 2018 22:01:53 +0000

This post was originally published in my blog smartpuffin.com.

Bonus: learn a surprising fact about the Fiji islands. 🇫🇯

Prerequisites

Here is a link to the repository where I have put the full source code for this post. You can download it and look at it while reading, or look at it afterwards.

And here is my previous article on unit testing topic explaining best practices in unit testing more widely.

Let's go!

Positive cases

Let's start with thinking about our method as of a black box.

We have this API:

// Returns distance in meters using haversine formula
double getDistance(double latitude1, double longitude1, double latitude2, double longitude2);

What can we test?

Putting yourself in a testing mindset

You need to switch from being a developer to being a tester now. This means you have to stop trusting yourself. You can't know your code is working if you didn't test it!

If you tested it manually, you don't know if it's going to work next time someone makes a change - in your code or close to it.

Moreover, you can be sure that whatever code you build on top of this well-tested piece, you have one less problem to worry about.

The feeling of security you have when your code is well-tested is incredible. You can refactor freely and develop new features further - and be sure your old code is not going to break.

Promise yourself a treat if you find a bug. But do be careful: too many cookies are bad for your health.

First test

Okay, we are ready to test! What should we test first?

The very first thing that comes to mind, is:

Calculate the distance between two points and compare with the true real number calculated manually. If they match, all is well!

And this is a great testing strategy. Let's write some tests for that.

I'll pick a couple of points: one in the very north of the Netherlands, one - in the very south. Practically, I want to measure the country from top to bottom.

I clicked at a couple of points on the map and got this:

Point 1: latitude = 53.478612, longitude = 6.250578.
Point 2: latitude = 50.752342, longitude = 5.916981.

I have used an external website to calculate the distance and got 304001.021046 meters. That means the Netherlands are 304km long!

Now, how do we use this?

Thinking about domain area

We need to think about domain area-specific things. Not all of them are obvious from the code: some of them depend on the area, some - on the future plans.

In our example, the returned distance is in meters, and it's a double.

All this makes us think that we should compare our calculated value with our expected value with some precision.

Let's pick some value that is good for our domain area. To do that, we can remember about our domain area and requirements again. Would 1mm be fine? Probably it would.

And here is our first test!

double Precision = 0.001; // We are comparing calculated distance using 1mm precision
...
@test
void distanceTheNetherlandsNorthToSouth() {
    double distance = GeometryHelpers.getDistance(53.478612, 6.250578, 50.752342, 5.916981);
    assertEquals(304001.0210, distance, Precision);
}

Let's run this test and make sure it passes. Yay!

More tests

We calculated the distance across the Netherlands. But of course, it is a nice idea to double-check and to triple-check.

Your tests should vary - this helps you cast a wider net for these pesky bugs!

Let's find some more nice points. How about we learn how wide Australia is?

@test
void distanceAustraliaWestToEast() {
    double distance = GeometryHelpers.getDistance(-23.939607, 113.585605, -28.293166, 153.718989);
    assertEquals(4018083.0398, distance, Precision);
}

Or how far is it from Capetown to Johannesburg?

@test
void distanceFromCapetownToJohannesburg() {
    double distance = GeometryHelpers.getDistance(-33.926510, 18.364603,-26.208450, 28.040572);
    assertEquals(1265065.6094, distance, Precision);
}

Now that we think about that: are we sure that the distance doesn't depend on the direction in which we are calculating? Let's test that as well!

@test
void distanceIsTheSameIfMeasuredInBothDirections() {
    // testing that distance is the same in whatever direction we measure
    double distanceDirection1 = GeometryHelpers.getDistance(-33.926510, 18.364603,-26.208450, 28.040572);
    double distanceDirection2 = GeometryHelpers.getDistance(-26.208450, 28.040572, -33.926510, 18.364603);
    assertEquals(1265065.6094, distanceDirection1, Precision);
    assertEquals(1265065.6094, distanceDirection2, Precision);
}

Corner cases

Great, we have covered some base cases - the main functionality of the method seems to work.

We can have a cookie now - for going half-way through. 🍪

Now, let's stretch our code to the limit!

Thinking about the domain area helps again.

A good idea would be to write a test for it, don't you think?

@test
void distanceAround180thMeridianFiji() {
    double distance = GeometryHelpers.getDistance(-17.947826, 177.221232, -16.603513, -179.779055);
    assertEquals(351826.7740, distance, Precision);
}

Upon further thinking, I discovered one more tricky case - distance between two points which have the same latitude; but the longitude is 180 in one point and -180 in the other.

double distance = GeometryHelpers.getDistance(20, -180, 20, 180);
// Question to you, my reader: what is this distance?

Okay, we're done with that weird 180th meridian. We are sure about the 0th meridian though... right? Right? Let's test it too.

@test
void distanceAround0thMeridianLondon() {
    double distance = GeometryHelpers.getDistance(51.512722, -0.288552, 51.516100, 0.068025);
    assertEquals(24677.4562, distance, Precision);
}

What other cases can we come up with? I thought a bit and listed these:

How about poles? Let's calculate a couple of distances in the Arctic and Antarctica.
How about from one pole to another?
How about max distance on the planet?
How about a really small distance?
If both points are absolutely the same, are we getting 0 m distance?

What's inside

Negative cases

@test
void invalidLatitude1TooMuch() {
    assertThrows(IllegalArgumentException.class, () -> {
        GeometryHelpers.getDistance(666, 0, 0, 0);
    });
}

@test
void invalidLatitude1TooLittle() {
    assertThrows(IllegalArgumentException.class, () -> {
        GeometryHelpers.getDistance(-666, 0, 0, 0);
    });
}

Same tests we'll add for latitude2, and for both longitude parameters.

We're writing Java here, and the double parameters can't be null. But if you're using a language where they can, test for it!

If you're using a dynamically typed language, and you can pass a string instead of the number, test for it!

Wrapping up

You can see and download the source code for this tutorial here. Look at it and try to come up with some more useful testing scenarios.

ice-lenor / ExampleUnitTests

ExampleUnitTests

This is the source code for the tutorial about writing good unit-test suites.

Tutorial

See the tutorial here:

http://smartpuffin.com/unit-tests-tutorial/

What to do with this

Open the tutorial.
Open GeometryHelpers.java.
Open GeometryHelpersTest1.java. Review the test structure. Run the test.
Open GeometryHelpersTest2.java.
Compare the first test in GeometryHelpersTest1.java with the first test in GeometryHelpersTest2.java. See how even the smallest pieces of domain area knowledge are important?
Think about what else you could test. I'm sure there is something I missed!
Apply the best practices in your own project.
Like the tutorial? Share, like, subscribe, say thanks. I'll be happy to know it!

How to run tests

I run this with Intellij IDEA and Java 1.8+.

Download the source code.
Open the folder with the code in Intellij IDEA.
Open the file GeometryHelpersTest1.java. You'll see green "Run test" buttons next to line numbers. Press the one next…

View on GitHub

Here's some followup reading to learn about best practices in unit testing.

Unit testing: best practices

Elena ・ Mar 21 '18

#unittesting #codequality #testing

For your own projects, select the part that would benefit from testing the most - and try to cover it with tests. Think creatively! Make it a challenge, a competition with yourself!

Unit testing is fun!

When Not To A/B Test

Elena — Wed, 17 Oct 2018 22:01:47 +0000

This article has been first published in my blog smartpuffin.com.

As I plowed my way through A/B testing of more than 300 features, I was wondering: are there any cases when you don't want to A/B test?

It seems like an easy way to understand if the users love your new feature. If you introduce it to half the users, are they buying your product more than the other half? If yes, show it to all users. If no, scrap it and build something else.

Are there any cases when you don't want that conversion increase, but you'd rather have a feature right away?

Having thought about it, I came up with this list.

1. Legal

Your Legal department wants you to immediately put an important message in your footer.

Perhaps, you cannot legally sell your products in some country.

Maybe, a lawsuit requires you to display the user agreement in full, or to change an icon, or to remove a copyrighted photo, or to display some important information to your customers before they buy.

You don't mess with Legal. You really have to add this feature.

2. Accessibility

You change colors so that color-blind people can use your website.

You increase font size for people who are visually impaired to use your app easier.

Add alt-text to images. Improve content for screen readers. Increase text contrast. Add subtitles to your video.

Yes, people with disabilities might actually convert better after all these improvements, but since they are a small fraction of all users, it won't be visible on your graphs.

And overall, this seems like a decent thing to do.

3. Moral choice

Your website displays a large banner about "great discounts", but it is out of date, and they are not applicable anymore.

Maybe your algorithm for calculating the "lowest price" is broken and displays this motivational message on all products. Users start to suspect something when all prices are the lowest.

Perhaps, you advertise "free shipping", but only in fine print the user can see it's domestic only. This is a nasty surprise at checkout.

Maybe you display ads and suddenly see something indecent. Or you feature other people's articles, and find out they posted something that strongly requires immediate moderation.

This is worth fixing, even if it doesn't bring your company more money.

4. Bugfix

Your layout is broken. A button isn't working. A link leads to a non-existing page. The "Add to cart" button doesn't add a product to the cart. (Well, this last one will be noticed immediately.)

You can fix this right away.

5. New product

Sometimes, people can be too careful in introducing new products or large new features.

You did your user research. You talked with your customers. You know the demand. But you're reluctant to make this large step. You think: maybe I can introduce this large feature as a series of small changes, and test them all for conversion increase.

But sometimes it is not enough. Sometimes a large feature needs to be introduced in full, so that the users could try the full experience.

It is especially challenging when you don't have the control group. If it's a new product, who do you compare your users (that is, the treatment group) to?

Absolute numbers might work better in this case: for example, what percentage of users are becoming customers. After establishing this number, A/B tests can be run to improve it.

6. Small number of users

If the number of users is not enough to have a decent sample size, what is the point of running an A/B test?

7. Professional users

With these users, you have to be extremely careful. Imagine you write software for call-center people, whose bonus depends on how many calls per day they are taking.

Do you really want to run random A/B tests on that software, knowing that someone's compensation depends on chance?

Users might become less productive if a feature they are using 3000 times per day changes its appearance every now and then. If you use something very often, it becomes automatic, and you become very sensitive to changes. Imagine someone experiments with the key combination to save a file or to exit vim. You'll become many times less productive because of that small change - and very, very annoyed.

Yes, I really have worked on software where a particular feature was used up to 3000 times per day.

For professional users, a better approach is more often to introduce a change after having spoken with them. Ask them about their needs. Collect their requirements. Agree with them on a change. Document it. Give them a beta to try. Collect feedback. Improve. Release.

Conclusion

You might still want to introduce all listed changes as experiments. The reason for that would be to see if you're creating any negative impact with the change. Perhaps, your increased contrast doesn't work on some devices or in some browsers? Maybe you broke your cart completely when fixing that "add to cart" button? Perhaps, you have accidentally forbidden selling the product in all countries? Then you will see it in your metrics. An A/B test will act as a feature switch. You'll be able to quickly turn your feature off, fix, and retry.

But for many cases I listed, it wouldn't be the best decision to wait weeks and months to get a large sample size, then compare conversion - and turn the feature off if the conversion growth is not enough.

Some features deserve to live regardless of conversion increase they bring.

The Hunch: 4 Times I Felt It And 1 When I Didn't, And What Were The Consequences

Elena — Wed, 29 Aug 2018 17:00:00 +0000

This post was originally published in my blog smartpuffin.com.

I sometimes have this feeling: The Hunch™. It's when I sense there is something wrong with the project, with the requirement, or with the feature, even when everyone else is sure all is well.

When I sense this, I feel like a dog who picked up the scent. I follow the scent by asking questions, until I get my answer.

Here's how it happens.

Dataset Extension

Our Dev team asked the Data team to collect some new data, in order to extend our already existing dataset. We had 1000 items, and we wanted 5000 more. We told them how we want it to be prioritised, we agred on the timeline, and we left reassured.

The first deliverable was ready. They sent is a huge shared spreadsheet with 1 thousand rows. We were happy, since it meant we would soon have twice more data than before!..

I wrote a script to upload all this new data to our database. I found some small problems in the data, such as columns mixed up, or string values in numerical columns, and the Data team fixed them quickly. Nothing serious.

All was ready. I was (literally!) holding my finger above the Enter key, pressing which would upload the data to the live servers.

But I hesitated. I had The Hunch™. And so I didn't press enter.

I asked the Data team the very last (or so I thought) question:

"Do I understand it right: all this is the very new data? When we upload it, we'll have 2 thousand items, is that correct?"

No, they told me. They had decided to execute a clean-up project along with collecting new data for us. 600 rows in this spreadsheet are to be updated. Only 400 are to be created.

It took me a minute to gather my thoughts. Not a single time was the clean-up mentioned to us before. How happy I was that I asked!.. Had I uploaded the data, we would have gotten 600 duplicated items.

How, asked I, do I understand from the spreadsheet which items are new and which are old? Surely you have an ID column for updates?

No, they told me. There was no such column. There is no other way to understand that. They simply didn't realise we will have to know which exact items have to be updated - until I asked.

Long story short, after much discussion, they added the ID column for us, marked the updated items, and we uploaded all the data successfully.

But had I not have The Hunch™, had I not asked the question, we would have uploaded the bad data, and we would have learnt about it much, much later.

Square Miles Conversion

I saw a feature on our website, where some geo-math was involved. I immediately had The Hunch™: there must be a bug.

It turned out to be correct, there was a funny bug which was live on our website for 10 years, without anyone noticing.

New API idea

Our team was rebuilding a product. The original product was built some 15 years ago, and evolved chaotically.

My colleagues were in love with a particular idea. The new API was supposed to distinguish between 3 use cases that were the same in the old product.

I was very new to the team, and I wasn't completely sold on the idea. I felt like I didn't understand it enough. I thought it might be too complex for the end users. I estimated that a lot of work was needed to support the split, including categorizing the existing data and supporting backwards compatibility. In short, my first days in the new team were full of The Hunch™.

But I decided that my colleagues, knowing the domain area better than me, have thought about all this. I assumed they estimated the amount of work and agreed with it - before I joined them.

They assured me that yes, some work is needed to categorise the existing data into these 3 use cases, but it is rather straightforward. A person from my team will do that, and will ask 2 more data specialists for help. The results will be ready very soon. And meanwhile, why don't we go ahead with the implementation?

I voiced my concerns, but started to implement the new API.

A week after, we met to see how the data split was going.

All 3 data specialists who were categorizing the data disagreed on every single data entry.

I asked them some questions, and it became clear that they understood the use cases differently. Moreover, all my own team members - including myself - understood it differently as well.

Setting what's happening, my team members agreed to postpone the feature until there is more clarity on the use cases.

Had I not seen that the use cases and not thought through enough, we would have offered a half-baked product to our users, and we wouldn't be able to explain the reason to split the use cases to them.

Collaboration between two teams

I supervised implementing a cross-team task.

The problem was that many places used different APIs to fetch the same data. The APIs worked slightly differently and returned different results. The users saw different values and complained.

The task was to clean it all up. The purpose of the task was to:

Use one single API in all places, because:
We wanted to unify display.

Developer1 implemented new API calls in three places. For some reason, in two of them they overrided results and displayed something different based on some condition.

So we still had the same inconsistency as before. This solution sort of complies with purpose 1), but completely defeats 2).

Developer2 replaced the API call in one place that I pointed out as an example. Turned out, results were overrided further in the code, based on yet another condition.

Moreover, in the area of responsibility of Developer2 there was one more place with the old API. They didn't notice it and didn't make any changes to that place.

Again, this solution half-complies with 1), but is out of line with 2).

I found out about all this only when I replaced the API call in yet another place. While pushing my code, I felt The Hunch™. Because the task was so complex and distributed between several people, I decided to test all changes at once.

What I saw was that all of them were different from each other.

After all these efforts, customers were still confused by different data on different pages. The developers' time was spent twice. And again, it would have been noticed much later, had I not decided to double check.

When I failed

Long time ago, we were implementing a new GIS-system. Our old system was storing coordinates in the UTM-projection, which meant you can work with only a relatively small piece of map at a time.

In the new system, we wanted to have the map of the whole world.

We made a decision quickly: let's store coordinates in latitude and longitude, and always work with them like that. When we want to display them on the screen, we will project them as needed.

Our next decision was to split the map to tiles to display them on the screen. And here we also made the decision to use latitude+longitude. It seemed only logical.

I spent almost a month implementing the tiles on latitude+longitude coordinates. Doing math on the sphere is hard, and I made a lot of mistakes. It was taking forever. I just didn't seem to get it right.

Seeing how I struggle, a more senior developer proposed to scratch all that and make a decision to have tiles in flat projected coordinates, using the projection our customers were using the most.

I agreed reluctantly, since I still thought having "real" spherical coordinates was "right". I deleted the complex code and wrote the new one in just 3 days. It's been working perfectly ever since.

I didn't have The Hunch™ back then - and, as you can see, the team lost a month because I didn't think very well about the consequences of the decision - how complex the math would be to implement.

How to do it yourself

I see many people not thinking through all aspects of their tasks and decisions, from technical to product ones, to business ones, to data collection ones.

A task, even small and simple one, often involves much more than it seems. For developers, I wrote an article helping them to think about corner cases in advance, when coding. The similar advice is applicable to all other sorts of tasks.

Try to think about the problem from all angles. What other people it involves? Does it involve changing existing stuff, be it code or processes or data? Does it align smoothly with everything else? Is there a logical flaw?

It is like testing. You list positive cases, negative cases, and corner cases; you also test other classes your change could touch; you ask your users for help; etc.

It will almost definitely be cheaper and faster to spend some time investigating first, than to rush into implementation and fail later.

Knowing what is actually involved will help you with prioritization. If the task is large, you might decide to do a smaller one instead.

Sometimes, after looking at all aspects, you might make a decision to do the task with the flaw. You might decide to not care about a certain problem or make a trade-off. Still, you will make an informed decision, and not simply go with the flow.

C++ From The Past - I found C++ and OOP lectures I wrote back in 2008!

Elena — Wed, 04 Jul 2018 21:57:00 +0000

You can't possibly imagine what I found today! 😍
Back in 2008 I wrote a set of lectures on C++ and OOP for my uni, and never published them anywhere. Until today.

It's pure gold. 60 pages, so very detailed, with code samples and full source code files. It goes about incapculation, inheritance, polymorphism, const modifier (all these lovely int const * const), exceptions, memory management, reinterpret_cast's! Pointers vs references! Templates!! Auto_ptr's! Unicode support!! I was so smart :).

Here is the link. It is all in Russian. Enjoy! :)

UPD: in August 2019 I have learned that the lectures are still in use in my uni! They don't credit me, unfortunately, but i am still happy the lectures are useful to this day, 11 years later.

Okay, okay, why did I write any lectures at all? I wasn't a professor or a teacher, I was just a 2-year nerdy student, very much a C++ fan.

Why I wrote OOP lectures

When the OOP course started, in my second year of the university, I was so excited. I already knew what it was, but hoped to learn so much more.

I found all lectures before the start of the semester, and read them.

First lecture went: let's have a class to describe a point. It looked like this:

class Point {
public:
  int x;
  int y;
}

Second lecture described a line. The line was inherited from the point class and had two extra fields: x2 and y2.

class Line: public Point {
public:
  int x2;
  int y2;
}

I went: wait, whaaaat?..

Third lecture described a square, inherited from the line class, with four more fields: x3, y3, x4, y4.

At that point I started to suspect it was some sort of proof by contradiction. It wasn't. The lectures went on.

I went and talked with the professor. I told her it wasn't the best approach, and explained why. I offered to write new lectures for her, instead of homework. She said rather indifferently: yea, go for it. Why not.

That autumn semester in 2008 I wrote my own OOP lectures. I was so happy writing! I enjoyed the process, the result, and how I get to summarize my thoughts in a neat way.

To my classmates my lectures seemed to help much more than the original ones. That was a nice feeling too. I was helping!

In the end of the semester, I sent the finished lectures to the professor, got my A, and never heard back from her. I don't know if she credited me. I don't even know if she used them at all. I found my first job right after these lectures, and didn't have time to follow up.

I do hope she found them useful.

UPD: in August 2019 I have learned that the lectures are still in use in my uni! They don't credit me, unfortunately, but i am still happy the lectures are useful to this day, 11 years later.

But how come I never published them anywhere else?

How toxic community discouraged me from publishing

While still in progress, I posted the lectures anonymously on a Russian developers' forum and asked for feedback. Some developers answered and offered a couple of tips, but others asked why am I doing this: am I going to sleep with the professor? Is she young and beautiful? If not, why do I even bother?

When they discovered I am a woman too, the discussion went off on a tangent. They started discussing me instead, and how I possibly couldn't exist. Women can't code, everyone knows that. I must have pretended to be a woman to draw attention to my weak lectures. Laughable, really. Or was I ugly?

This was when I decided I don't want to post anything anymore.

It took me several (7? 8?) years to be not afraid to share my professional insights publicly. That's why I didn't have a blog for many years, and didn't speak on conferences. I was afraid I will be laughed at again.

Okay, my story about writing C++ lectures somehow turned into a sad story about toxic developers community. But hey, I overcame this, and I'm posing here now :).

Feeling sentimental

Why am I publishing the lectures now? It's been ten years, and they are hopelessly out of date. Since then, three new C++ standards were published. When I was writing them, the current standard was C++03, from 2003, and I thought the new standard will never ever be released.

So why now, in 2018?

Why, I am feeling sentimental, of course. And I don't want them to disappear. When I'm old and gray, I will be telling my grandchildren this story, while sitting in a rocking chair and drinking orange juice.

There was a time, I'll say, when your grandma was young...

Code Reviews Are Awesome, Here Are 7 Reasons Why

Elena — Wed, 20 Jun 2018 22:04:39 +0000

This post was originally published in my blog smartpuffin.com.

Code reviews are a great practice to apply in software development. The approach is very simple: when you're done with your code, give it to someone else to look at and leave comments.

Despite of its simplicity, it brings considerable advantages. Here are 7 reasons why this practice is useful.

1. Finding bugs

Another developer, just by looking at your code, may find bugs or forgotten scenarios.

No one writes perfect code all the time. A second pair of eyes is really helpful.

Even quality assurance engineers can miss some obscure cases which can easily be spotted by looking at the code with fresh eyes.

2. Finding problems

You can spot cases when it is not strictly a bug, but something still can be improved. Think questions like this:

"This is not exactly a bug, but do you think it would be better if we did X instead?"
"If there are too many elements, this method is going to be slow. How about we sort the items first and use the binary search? How about we use a hashmap, a heap, a graph, a set, a smart algorithm, an index on this field, a garbage collection trick?"
"Maybe we should normalize these tables and not duplicate this data?" (Or, perhaps, the other way around.)
"A test is missing for the situation N."
"When the user does X, the system behaves in way Y. But maybe users would prefer Z?"
"You implemented something that was missing from the specification, let's figure out what it should be."

Here are some tips about how to improve your thinking about corner cases.

3. Improving code quality

You might be using a static analysis tool, such as StyleCop for C#, Checkstyle for Java, or Lint for CSS. However, the tool cannot catch all problems.

For example, a reviewer can give an advice about a class name, or how to split the logic between methods, or how to separate responsibilities between modules or services.

Overall, the reviewer should be able to read the code easily. After all, we read the code 10 times more often than we write it.

A developer writing the code is so immersed into the context that they understand everything. However, after a couple of months all knowledge is lost, and your own code looks as unfamiliar as if someone else's. So making the code readable is for your own benefit.

And what is the better way than, you know, ask someone to read it?

4. Testing

The reviewer runs your code to see if it's working, and how exactly. By doing that, they may find some bugs. This is great because it helps you to publish a better product, you get the feedback faster, and the load on the QA is reduced.

5. Educating junior developers

It would be a mistake to think that junior developers cannot or shouldn't review the code of more senior ones. They are very much able to find bugs or problems with code readability.

But another important aspect is that they learn how to do things. By giving them your awesome code to review, you teach them on an example.

6. Sharing the knowledge

A team member, while reviewing someone else's code, learns about the part of the system which is being changed. They build a better understanding of the system as a whole.

And next time they have to implement a feature in that area, they are prepared.

7. Building trust

I know this one sounds a bit strange. How am I supposed to trust the colleagues who are going to criticize me?!

But hear me out. Code reviews, when everyone in the team is doing them equally, help the team members to feel like they are being trusted. It builds the sense of reciprocity. If you are asked to review someone's code, you feel like they respect you and your opinion. If you ask someone to review your code, you show that you value their input and are open to feedback and improvement.

You need to make sure to criticize constructively and not attack or condescend. If someone says to you: "that's a horrible code", no trust is going to be built for sure. It is demotivating and simply annoying. You are not going to want to ask that person anymore.

The feedback should be given in a kind and constructive way, and make sure (!) to always (!) explain the reasons. Absolutely do explain why you think it should be done in a different way. You found a bug? You found a problem? You cannot read it easily? Does it not play along with other parts of your system? Explain that.

If you can give a constructive advice about how to do it better, that's the best.

Do you do code reviews? What does the process look like? What advantages do they have for your team? Please share with me, I'd love to know!