Restocks was started with a great love and passion for sneakers and is Netherlands first reseller platform for limited addition sneakers.

Since their launch, Restocks has experienced continued growth and has expanded all over Europe and the world. To help them continue to grow, Keepitswift was asked to help plan, create and launch their first iOS native applications.

This project is only just beginning. More details will be added here when they become available.

If you've read our other posts, then you know what to do when opening a pull request and what to look for when reviewing one. In this post, we will offer some tips and general customs to follow when working with pull requests.

Fast response times

Pull requests should not be open for a long time otherwise they will go stale. To help prevent this from happening, reviewers should start reviewing as soon as they possibly can. If any comments are left, then these should be answered and/or addressed quickly.

Keep it small

A small pull request will get looked at much quicker than a large one, because it is less overwhelming and isn't as scary looking. It is also easier to review and less prone to letting errors through.

As mentioned in Reviewing a Pull Request, keep the pull request on topic and don't include out of scope work. If you see a change is going to lead to a large pull request, consider splitting it up into multiple smaller pull requests.

Have a meeting

Sometimes a pull request can't be kept small, is very complex or creates great discussion between project members. If this is the case and it's possible, try to have a face-to-face meeting where you can discuss the pull request together and even make any necessary changes to the pull request.

It's often easier to come to agreements and explain complexities when you can talk to each other, rather than typing over comments. Just remember to keep the pull request up-to-date with any developments from the meeting.

Separate renames into their own pull request

Renaming classes, variables or functions can result in a big code change. If there is also a change to the functionality, it can be difficult to visualise the change amongst all the renaming. To solve this issue, you should instead do the renaming in its own branch, which will have its own pull request.

Be polite

Politeness will get you a long way in life. When leaving comments on a pull request, or responding to comments, talk in a respectable manner. If project members fail to do so, it can lead to conflicts between project members that can result in the deterioration of the project as a whole.

Suggestions over enforcement

Everyone has their own preferences. Unless there is a specific guideline enforced by the project standards, only offer suggestions. If there is a difference of opinion, raise this outside of the pull request. There is no need to hold up a pull request over personal preferences.

Give reasons and improvements

If you don't agree with a change, you should explain your reasons for this and offer suggestions for how you believe it could be improved. This will help the author to understand your concern and be able to address it better.

Request early review

Some projects may allow for authors to request a review of their change before they are fully complete. This can be useful if an author wants to ask for some feedback on the approach they have taken.

It's a good idea to add a work in progress tag at the start of your pull request title. Something such as "[WIP] - Title".

Show appreciation

A pull request isn't only for highlighting mistakes or bugs. Both authors and reviewers can show appreciation to each other. Appreciation can go a long way to making a person's day that much better.

Make it fun

Pull requests are boring, we all know it! But you can add bits of fun here and there. Make use of emojis and GIFs to add a bit of cheer to your comments.

Review others pull requests

Don’t only open pull requests. Review other projects members pull requests too. You don’t need to maintain a 1:1 ratio of opened to reviewed pull requests, but it's only fair that if other project members are spending time on your pull requests, you do the same back.

So there are some general customs you can follow when both authoring and reviewing pull requests. Hopefully you find them helpful.

Being asked to review a pull request can be a daunting task, but it is a very important one. The goal is to assert that the change does what it sets out to do and in a logical way.

Here we will go over some tips and best practices you can follow when reviewing a pull request.

Understand what you’re reviewing

In order to efficiently review a pull request, you need to fully understand what you are being asked to review. Read any information provided in the pull request description thoroughly. If there is an issue tracking number attached to the pull requests, open that issue and read what its all about, so you can get a complete understanding of the issue at hand.

If you don't understand the change that you are reviewing, then you cannot approve it. Doing so could lead to unsatisfactory code entering production. Instead, leave a comment on the pull request asking for clarification or talk directly with the author.

Take your time

This is the last chance to prevent erroneous code from entering production. Thus, it is important that you read every line of code that has changed. It is far better to spend an hour or more reviewing the change than letting a bug enter production. It would likely take you and/or other project members much longer to debug and resolve the bug afterwards. On top of that, you will have potentially released a buggy application to your users.

Check the commit messages and branch name

Having good commit messages and branch names makes it much easier to find where changes happened without having to dig into the code itself. This can be very helpful in the future for finding when a particular change in the project occurred.

Check that the commit messages follow the team standards and reference any relevant issue numbers. The same applies for the branch name.

Check the acceptance criteria

Acceptance criteria are there for a reason and so you must ensure that the author has met all the criteria set out. If they haven't, then the pull request is not finished. You should leave a comment informing the author of the missing acceptance criteria.

If any missing criteria "will be addressed in a separate pull request", make sure that the author has created a relevant issue for this and left a TODO comment in the codebase that links to said issue.

Check for any out of scope work

It is often very tempting for a pull request author to sneak in out of scope work. Whilst it may seem like a quick win, it can actually distract from the acceptance criteria of the story. Also, there will be no reference to this change in your issue tracker.

This goes both ways though. A reviewer should not request out of scope work to be fixed in the current pull request. In both cases, create an issue and separate pull request for the out of scope work.

Code readability

The code contained within the pull request will eventually be merged into the codebase. It is therefore important that the code is readable. This sometimes means opting to write more lines of code, rather than shorter and more complex code.

Some topics to keep in mind when checking for code readability are:

• Large functions
• A large number of nested conditions
• Magic numbers
• Ambiguous variable and/or function names
• Unused code

Clean code

Just as the readability of the code is important, so is the fact that it's kept clean. Even if using linters, some styling issues can still sneak through. Thus, you must keep an eye out for them when reviewing code changes.

Some topics to keep in mind when checking for clean code are:

• Correct indentations
• Typos in comments, variable names and function names
• Incorrect grammar in comments
• Duplicate code/functionality
• Duplicate or overly large assets
• Unused code is removed

Shorter code

Whilst keeping code readability in mind, you should keep an eye out for code which could be shorter whilst still being easy to read and understand.

Things to look out for include:

• Functions with duplicated code
• Is there a shorthand syntax available?
• Returning a boolean rather than a condition

Optimal solution

It is very important to confirm that the solution is optimal. You want to ensure that build and/or execution times do not deteriorate, as this will slow down the development process. Non-optimal solutions can also have a negative effect on the user experience of the app.

Tests

If the project makes use of tests, and it should, it is important that the author has included them in the pull request. Unit tests are another tool that helps prevent bugs from entering production, so it is a must that you review these tests with the same attention to detail as the code itself.

Other test types such as UI and snapshot tests (if used) should also be included.

Other project standards are met

Every project is unique and will have its own set of standards. These should be set out and clear for everyone working on the project. Reviewers should assert that all these standards are met.

Examples of project standards include:

• Documenting code
• File headers
• Project structure
• Variable and function naming
• Anything else your project team desires

You should now have a better understanding of how to go about reviewing pull requests. The more pull requests you review, the more natural this will all come to you.

To get some more tips that can be used by both authors and reviewers, read our Pull Request Tips and Customs post.

Once your change is complete and you’ve reached the definition of done, you're ready to open a pull request and start inviting project members to review it. You want the members to understand the aim of your pull request as quickly as possible. Therefore, you should provide as much detail as possible when opening a pull request.

Here you will find a few simple steps that you can follow when opening a pull request. If necessary, these steps can be altered and/or expanded depending on the requirements of the project you are working on.

Provide a short summary title

A short summary title allows the reviewers to get a brief idea of what they're going to review. It also allows a pull request to be found with ease, which is a great help when working on a project which has many open pull requests. Try to describe the change is in as few words as possible as long titles will usually get truncated.

When using an issue tracking system, including the issue number at the beginning of the title is a good idea. This will allow the reviewers to find all the relevant information, such as acceptance criteria, steps to reproduce, required credentials, etc. Many version control repository hosts are able to detect issue numbers and link them directly to the issue itself.

Use the description box

If not using an issue tracking system, you can add any extra information into the pull request description box. The description box is also a good place to provide explanations for decisions made during your change. This is especially helpful if your change is complex or has some changes that you know could raise eyebrows.

As well as providing steps to reach functionality, required credentials, known issues, etc, you can also provide screenshots and/or screen recordings if you have made a change to the UI. It is advisable to add both before and after screenshots and/or screen recordings. This will allow for other project members to easier visualise the change and may help you spot undesired results.

Review your own pull request

Most pull requests systems will allow you to check your own pull request before opening and sharing it with other project members. Doing this step will give you an overview of your whole change. You will often discover accidentally committed code, commented out code, overcomplicated logic, amongst many other things you may wish the other project members didn’t see.

You can also take this moment to add comments to your pull request. This way, you can pre-empt questions that reviewers will ask, add links to documentation or blog posts that explain your solution. Or even to ask reviewers for a better solution if you believe your own is not optimal.

You should review your own change just the same as the other project members will review it. To find out more about how to review a pull request you can read our post about it here.

A pull request allows members of a project to be notified of a proposed change. It also acts as a forum where the members can review the change and offer constructive feedback. Once approved the change can be merged into the branch.

When working within a team, or on any other project with multiple contributors, pull requests are an important tool for reasons we will go over now.

Code Quality

When used correctly, pull requests help to maintain a clean and high quality codebase. This in turn helps to prevent bugs from entering production code.

During a pull request reviewers can confirm the author’s logic, if the acceptance criteria has been met, adherence to project coding standards and much more as you can read in Reviewing a Pull Request.

Knowledge Sharing

Whether new or not, there is often knowledge either to learn or to pass on when interacting with other likeminded developers. Pull requests are a great learning opportunity for everyone involved.

As well as sharing new methodologies, shorter syntax options, the latest technologies etc, you also pass on the knowledge of the functionality itself. Having more people aware of the functionality means you won't need to rely on one person to work on this feature moving forward.

Streamlined Workflow

The last to mention, but by no means the least beneficial, is that all pull request activity gets tracked in one place. Comments can be left directly next to the changes and can begin a thread of conversation. These conversations can be seen by anyone with access to the project.

This streamlined workflow will save you lots of time and energy, as you won't need to be constantly searching through your emails and chat history.

If you're looking to make the best use of your pull requests, make sure to read our other posts on this topic.

Tests are an important part of any project and should be written to the same standards of your production code. In this post we will cover how you can use a test naming convention to help keep your test names clear and easy to understand.

We will be approaching this from the Apple world of XCTest, but the same approach can be used for any development project where tests are being utilised.

Why should I care?

Being able to easily understand what is being tested and under which circumstances will help you in many ways. A few examples are:

• Less likley to miss scenarios that need testing
• Quick feedback when tests fail
• Easier to maintain tests as functionality evolves
• Easier to find and remove redundant tests
• Consistency in test naming

What makes a good test name?

A good test name should provide the following information:

1. What is being tested
2. Under which circumstances is is being tested
3. What is the expected result

Having all this information provided in the test names prevents you and other project members from having to read through the test code to determine what is being tested.

How to write good test names?

As established above, a good test name consists of three elements. Using these elements, we can come up with a convention that can be followed when naming a unit test. For example, we could use the following convention:

By simply using the three elements of information mentioned above, we can come up with an easy to use naming convention.

func testWhatIsBeingTestedUnderWhichCircumstancesWhatIsTheExpectedResult {}

The elements can be simplified down to:

func testMethodNameCircumstancesExpectation {}

We can further add clarity to the test name with the addition of the keywords with and should:

func testMethodNameWithCircumstancesShouldExpectation {}

One last step we can take is to introduce underscores (_) to the test names, in combination with camel case. Whilst it may seem strange to use underscores, it makes them much easier to read and understand at a glance. So now we end up with our final naming convention:

func test_methodName_withCircumstances_shouldExpectation {}

Real world examples

Now that we've described a naming convention, lets see how it can be applied to some real life tests. Below are a couple of real test names taken from the Albert Heijn iOS codebase, before they implemented the test naming convention.

func testStartStoreBonusCardShouldTriggerStateChangedToBusyForAuthenticatedMember {}
func testEndStoreBonusCardShouldTriggerStateChangedToIdleForAuthenticatedMember {}

With these test names it is very difficult to get an understanding of what is being tested, under which circumstances it is being tested and what the expected result is, especially with a quick glance.

It is quite easy in this situation for a developer to waste time looking for a method named startStoreBonusCard and/or endStoreBonusCard. They will come up empty handed though as these methods do not exist in the codebase.

The method that is actually being tested here is storeBonusCard. Having start and/or end prefixed to the method names really adds no value and only leads to developer confusion on what is actually being tested. The developer is forced to dig into the test and method code before they can begin to understand what is being tested and why.

By adopting the test naming convention, we can vastly improve the readability of the unit test names and instantly get understanding of what is being tested, under which circumstances and what the expected result is.

Here is the result after applying the test naming convention to these tests:

func test_storeBonusCard_withAuthenticatedMember_shouldSetStateToBusy {}
func test_storeBonusCard_withAuthenticatedMemberAndSuccessResponse_shouldSetStateToIdle {}

And there we have it, these unit tests names are now much easier to read and understand. This will help speed up your development time greatly and help keep sanity within the development team.

Should I rename all my tests?

Now that you've decided to adopt a test naming convention, you're probably dreading the task of applying this to all your existing tests. There is no need to worry though.

The best approach to take is to apply the naming convention to all new tests that are written. Existing tests can be updated when an change to the test is required. For example, when the functionality has been updated. Overtime, all your tests will come to use this naming convention.

What else can be done to improve tests?

Applying a test naming convention is just a starting point. In fact, the convention discussed here is by no means perfect. It can create long tests names which become exceptionly long when you have many variables making up the circumstances under which the test is ran.

If you're intersted in keeping your test names short, you can read this post by Victor Magalhães. Here he discusses a method that allows you to describe tests in the test code itself. Whilst this is not exactly our favourite method, it is definitely worth the read. Maybe it can meet your needs.

As well as readable test names, you need to have readable test code. It should be written with a good structure too. There are also other approaches you can take to writing tests, that can help you to write more concise tests. Make sure to keep checking back here if you're interested in reading more about good practices for writing tests.

For now, happy testing!

Ahold Delhaize is a Dutch grocery retail company. Its business format includes supermarkets, convenience stores, hypermarkets, online grocery, online non-food, drugstores, and liquor stores. These include Albert Heijn, Etos, Gall & Gall and Bol.com in the Netherlands.

Keepitswift was tasked with helping their Albert Heijn supermarket brand maintain and add new features to their iPhone and iPad applications. Such as digitalising "Koopzegels" and "Mijn Bonus Box". These were both planned and built with the help of a large variety of Albert Heijn departments working together.

As well as building new features, Keepitswift was able to bring the knowledge it has built up over the years to help the Albert Heijn IT department (not just iOS) improve its practices. Such practices that were improved include unit test naming, pull request processes and much more.

Dott is an European micromobility operator, operating electric scooters in cities all over Europe.

Keepitswift was asked to help plan and release the first versions of the Dott mobile app that their customers would use to rent Dott electric scooters. This involved planning the app from the ground up, architecting the app, devising coding standards and of course, writing the code for the app.

With the help of a small team, we managed to go from nothing to a fully featured app that matched the feature set of already existing competitors. All of this in a just a few months!

Django Web Studio & Arcadis work together to create the Arcadis iPad survey tool for the inspection of buildings. Keepitswift was asked to help improve the user experience, debug ongoing issues, as well as maintaining and adding new features.

As this project was originally created in 2012, it was written in Objective-C and contained a great deal of legacy code which made it quite a challenging project to work with at times. However, by taking a pragmatic approach to debugging and problem solving, we was able to overcome all issues.

Whilst working on this project, we offered consulation too. We made future plans for how the project will be improved, both in the scope of code changes as well as procedural changes. Such as integrating Fastlane, a CI setup, unit testing, etc.

If you're interested in working with Keepitswift, then please feel free to contact us via our contact form. We will get back to you as soon as we can!