Django Machine Test Cheat Sheet | Best practices

TLDR;
In this blog i have shared a few tips which you should follow in your django machine test.

Hii guys, writing a blog after a long time as I am currently working as a python full stack developer which takes most of my time. In this blog, I have shared some general best practices that most of the new programmers miss in their Django machine tests. Unfortunately, most of these are very crucial and the person evaluating your machine test is expecting you to have followed these best practices.

What is a machine test?
A machine test is an interview round in which you are given a problem statement and you have to provide the solution to the problem statement. Most probably when you are applying for the Django developer position the machine test is to make an API as Django is mostly used in the backend to make APIs.

A naming convention is generally agreed on rules which are followed for naming variables, functions, classes, etc. Naming conventions is very important as it increases the readability of your code. Different programming languages have different naming conventions as of now let's focus only on naming conventions for python. The names in your code should always have a meaning and should relate to the logic of the code.

Variables should be written as a lowercase single word or an underscore should be used if multiple words.

Functions should be written as variable names with lowercase and underscore if multiple words are used. But often we write functions that are used only for a particular thing such function names should be self-explanatory, getter/setter functions should be written using the “get_” or “set_” prefix.

Class names should start with Uppercase and every word of class name should start with uppercase.

db_table option gives flexibility to the user for specifying a database table name, the name of database tables should be singular.

Project dependencies

The version of libraries and dependencies can be different in your workspace and someone else’s workspace, thus it is your responsibility to mention what are the requirements and dependencies which are required to run your projects. You should always use a virtual environment and maintain the project requirements in a file called requirements.txt. This file can be generated automatically by a simple command. Make sure you use this command after adding any new dependencies so that the file gets updated.

pip freeze > requirements.txt

Environment variables

It is a very bad practice to upload your credentials and third-party API keys to Github/GitLab etc, to avoid this these credentials are stored in environment variables ( .env ). You can use the below package for this.

Documentation

It is very important to document your project, writing a brief readme is more than enough for this purpose. The blog below is a good starting point for writing a readme. Do not forget to add images of the endpoints or functionality which were asked to be made in the problem statement.

You should also add API Documentation, this could be done very easily using the below package, all you have to do is include few URLs in the urls.py file.

Last, but not least!

God forbid, but if you ever have to copy-paste your friend’s project or if you find the exact same project on GitHub, at least change the secret key of your project. Thanks for reading, if you have any more tips then please comment down.

Python Full Stack Dev | GO | Security Enthusiast | Bug Bounty | Automation