SiteLint documentation and guidelines

Best practices for software development and testing

A person who holds books
On this page
  1. Software development
    1. Maintaining dependencies
    2. Before including dependencies
    3. The threshold for the maximum package size
    4. Avoid submitting changes when you won’t be around
    5. Disable loading some dependencies while development
    6. Fix reported errors and warning
    7. What’s slowing down your software development
  2. Testing

Software development

Maintaining dependencies

Keep upgrading your dependenciesKeep upgrading your dependencies, like npm packages. If you do it in a short period of time then fixing eventual issues is much easier than trying to upgrade and fix issues after a very long time.
Review your dependenciesKeep reviewing your dependencies 1-2 times per year. There is a chance that some of them could be removed or replaced with other solutions.

Before including dependencies

Determine dependency sizeIf you use npm packages, use bundlephobia service to check the package size. Example for @sitelintcode/optimize-image-on-the-client-side package. However, double-check the original repository and check the distributable package size. There might be some differences between bundlephobia service calculation and the real distributable package size.
Determine last publish dateThe last date change determines the freshness of the packages. At least, at some level of degree. You better avoid including very old packages that may not be up-to-date.
Determine how long it takes to resolve the issueWhen you find a bug, it’s good practice to report it to the author. However, check the list of previously reported bugs and feature requests and determine how long it takes from the date of request to the date of the published solution. You don’t want to wait a couple of years for the issue to be resolved.
MaintenanceHow many items (bugs or requests for new features) are submitted? How many have been solved? How many have not been resolved? What is the date of the oldest unsolved problem? This will allow you to determine the average response to the questions asked, reported problems, or requests for new functionalities.
Determine if the problem can’t be solved with a few lines of codeOften, there are already built-in methods (e.g. Date, Intl.DateTimeFormat) that can greatly provide the solution to the problem. You don’t need to attach a 0.5MB package just to calculate what day of the week it was yesterday. Besides, writing code makes your experience stronger. Note that this doesn’t mean you should always write the code on your own. Just evaluate possibilities and then decide whether to use an external solution or not to use.

The threshold for the maximum package size

Avoid increasing the threshold for the package sizeBe disciplined and if the application size is exceeded, stop the work and look for a solution to reduce the application size. For example, look for a code that is no longer used. Or sometimes some dependencies are no longer used but are still part of the application.
Experiment with decreasing the threshold for the package sizeIt will trigger a reminder to review the app size.

Avoid submitting changes when you won’t be around

Don’t push changes if you won’t be aroundPushing changes to the development branch and leaving it without your support may lead to unexpected consequences. Other engineers may pull the changes and the whole build might be broken or working in unexpected ways. To avoid that, we strongly recommend not pushing the changes till you’re not around to support in case of any failure.

Disable loading some dependencies while development

Disable loading some dependencies when you don’t need them locally

Sometimes it might be handy to disable loading some dependencies. For example, user traffic analytics or chat. That way, your local app may load and work faster. This will make also your environment more clean, as nothing from disabled dependencies impacts your app. It’s easier to spot the root cause of potential issues.

An example of the Network Request Blocking option in Brave browser:

Network request blocking tab in Development panel, Brave browser

However, use that approach with caution because you need to test your features within all available dependencies.

Fix reported errors and warning

Keep console error and warning cleanEnsure all reported console errors and warnings are in your software development review loop and processed as soon as possible. In most cases, console.error is a sign that something’s gone wrong. While console.warn tends to be ignored due to its nature, we recommend not ignoring the warnings but rather reviewing them and checking whether they are understandable and whether they are up-to-date.

What’s slowing down your software development

Unclear steps to reproduce in bug reportWhen reporting the issue, ensure the steps to reproduce are clear.

Testing

Keep test cases clearSet test steps clearly so that the logic of expected behaviour can be determined from the specified steps, not from reading the code.