One place for hosting & domains

      How To Add Unit Testing to Your Django Project


      The author selected the Open Internet/Free Speech Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      It is nearly impossible to build websites that work perfectly the first time without errors. For that reason, you need to test your web application to find these errors and work on them proactively. In order to improve the efficiency of tests, it is common to break down testing into units that test specific functionalities of the web application. This practice is called unit testing. It makes it easier to detect errors because the tests focus on small parts (units) of your project independently from other parts.

      Testing a website can be a complex task to undertake because it is made up of several layers of logic like handling HTTP requests, form validation, and rendering templates. However Django provides a set of tools that makes testing your web application seamless. In Django, the preferred way to write tests is to use the Python unittest module, although it is possible to use other testing frameworks.

      In this tutorial, you will set up a test suite in your Django project and write unit tests for the models and views in your application. You will run these tests, analyze their results, and learn how to find the causes of failing tests.

      Prerequisites

      Before beginning this tutorial, you’ll need the following:

      Step 1 — Adding a Test Suite to Your Django Application

      A test suite in Django is a collection of all the test cases in all the apps in your project. To make it possible for the Django testing utility to discover the test cases you have, you write the test cases in scripts whose names begin with test. In this step, you’ll create the directory structure and files for your test suite, and create an empty test case in it.

      If you followed the Django Development tutorial series, you’ll have a Django app called blogsite.

      Let’s create a folder to hold all our testing scripts. First, activate the virtual environment:

      • cd ~/my_blog_app
      • . env/bin/activate

      Then navigate to the blogsite app directory, the folder that contains the models.py and views.py files, and then create a new folder called tests:

      • cd ~/my_blog_app/blog/blogsite
      • mkdir tests

      Next, you’ll turn this folder into a Python package, so add an __init__.py file:

      • cd ~/my_blog_app/blog/blogsite/tests
      • touch __init__.py

      You’ll now add a file for testing your models and another for testing your views:

      • touch test_models.py
      • touch test_views.py

      Finally, you will create an empty test case in test_models.py. You will need to import the Django TestCase class and make it a super class of your own test case class. Later on, you will add methods to this test case to test the logic in your models. Open the file test_models.py:

      Now add the following code to the file:

      ~/my_blog_app/blog/blogsite/tests/test_models.py

      from django.test import TestCase
      
      class ModelsTestCase(TestCase):
          pass
      

      You’ve now successfully added a test suite to the blogsite app. Next, you will fill out the details of the empty model test case you created here.

      Step 2 — Testing Your Python Code

      In this step, you will test the logic of the code written in the models.py file. In particular, you will be testing the save method of the Post model to ensure it creates the correct slug of a post’s title when called.

      Let’s begin by looking at the code you already have in your models.py file for the save method of the Post model:

      • cd ~/my_blog_app/blog/blogsite
      • nano models.py

      You’ll see the following:

      ~/my_blog_app/blog/blogsite/models.py

      class Post(models.Model):
          ...
          def save(self, *args, **kwargs):
              if not self.slug:
                  self.slug = slugify(self.title)
              super(Post, self).save(*args, **kwargs)
          ...
      

      We can see that it checks whether the post about to be saved has a slug value, and if not, calls slugify to create a slug value for it. This is the type of logic you might want to test to ensure that slugs are actually created when saving a post.

      Close the file.

      To test this, go back to test_models.py:

      Then update it to the following, adding in the highlighted portions:

      ~/my_blog_app/blog/blogsite/tests/test_models.py

      from django.test import TestCase
      from django.template.defaultfilters import slugify
      from blogsite.models import Post
      
      
      class ModelsTestCase(TestCase):
          def test_post_has_slug(self):
              """Posts are given slugs correctly when saving"""
              post = Post.objects.create(title="My first post")
      
              post.author = "John Doe"
              post.save()
              self.assertEqual(post.slug, slugify(post.title))
      

      This new method test_post_has_slug creates a new post with the title "My first post" and then gives the post an author and saves the post. After this, using the assertEqual method from the Python unittest module, it checks whether the slug for the post is correct. The assertEqual method checks whether the two arguments passed to it are equal as determined by the "==" operator and raises an error if they are not.

      Save and exit test_models.py.

      This is an example of what can be tested. The more logic you add to your project, the more there is to test. If you add more logic to the save method or create new methods for the Post model, you would want to add more tests here. You can add them to the test_post_has_slug method or create new test methods, but their names must begin with test.

      You have successfully created a test case for the Post model where you asserted that slugs are correctly created after saving. In the next step, you will write a test case to test views.

      Step 3 — Using Django’s Test Client

      In this step, you will write a test case that tests a view using the Django test client. The test client is a Python class that acts as a dummy web browser, allowing you to test your views and interact with your Django application the same way a user would. You can access the test client by referring to self.client in your test methods. For example, let us create a test case in test_views.py. First, open the test_views.py file:

      Then add the following:

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 200)
      

      The ViewsTestCase contains a test_index_loads_properly method that uses the Django test client to visit the index page of the website (http://your_server_ip:8000, where your_server_ip is the IP address of the server you are using). Then the test method checks whether the response has a status code of 200, which means the page responded without any errors. As a result you can be sure that when the user visits, it will respond without errors too.

      Apart from the status code, you can read about other properties of the test client response you can test in the Django Documentation Testing Responses page.

      In this step, you created a test case for testing that the view rendering the index page works without errors. There are now two test cases in your test suite. In the next step you will run them to see their results.

      Step 4 — Running Your Tests

      Now that you have finished building a suite of tests for the project, it is time to execute these tests and see their results. To run the tests, navigate to the blog folder (containing the application’s manage.py file):

      Then run them with:

      You’ll see output similar to the following in your terminal:

      Output

      Creating test database for alias 'default'... System check identified no issues (0 silenced). .. ---------------------------------------------------------------------- Ran 2 tests in 0.007s OK Destroying test database for alias 'default'...

      In this output, there are two dots .., each of which represents a passed test case. Now you’ll modify test_views.py to trigger a failing test. First open the file with:

      Then change the highlighted code to:

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 404)
      

      Here you have changed the status code from 200 to 404. Now run the test again from your directory with manage.py:

      You’ll see the following output:

      Output

      Creating test database for alias 'default'... System check identified no issues (0 silenced). .F ====================================================================== FAIL: test_index_loads_properly (blogsite.tests.test_views.ViewsTestCase) The index page loads properly ---------------------------------------------------------------------- Traceback (most recent call last): File "~/my_blog_app/blog/blogsite/tests/test_views.py", line 8, in test_index_loads_properly self.assertEqual(response.status_code, 404) AssertionError: 200 != 404 ---------------------------------------------------------------------- Ran 2 tests in 0.007s FAILED (failures=1) Destroying test database for alias 'default'...

      You see that there is a descriptive failure message that tells you the script, test case, and method that failed. It also tells you the cause of the failure, the status code not being equal to 404 in this case, with the message AssertionError: 200 != 404. The AssertionError here is raised at the highlighted line of code in the test_views.py file:

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 404)
      

      It tells you that the assertion is false, that is, the response status code (200) is not what was expected (404). Preceding the failure message, you can see that the two dots .. have now changed to .F, which tells you that the first test case passed while the second didn’t.

      Conclusion

      In this tutorial, you created a test suite in your Django project, added test cases to test model and view logic, learned how to run tests, and analyzed the test output. As a next step, you can create new test scripts for Python code not in models.py and views.py.

      Following are some articles that may prove helpful when building and testing websites with Django:

      You can also check out our Django topic page for further tutorials and projects.



      Source link

      How To Add Swap Space on Ubuntu 20.04


      Introduction

      One way to guard against out-of-memory errors in applications is to add some swap space to your server. In this guide, we will cover how to add a swap file to an Ubuntu 20.04 server.

      Warning: Although swap is generally recommended for systems using traditional spinning hard drives, placing swap on SSDs can cause issues with hardware degradation over time. Due to this, we do not recommend enabling swap on DigitalOcean or any other provider that uses SSD storage.

      What is Swap?

      Swap is a portion of hard drive storage that has been set aside for the operating system to temporarily store data that it can no longer hold in RAM. This lets you increase the amount of information that your server can keep in its working memory, with some caveats. The swap space on the hard drive will be used mainly when there is no longer sufficient space in RAM to hold in-use application data.

      The information written to disk will be significantly slower than information kept in RAM, but the operating system will prefer to keep running application data in memory and use swap for the older data. Overall, having swap space as a fallback for when your system’s RAM is depleted can be a good safety net against out-of-memory exceptions on systems with non-SSD storage available.

      Step 1 – Checking the System for Swap Information

      Before we begin, we can check if the system already has some swap space available. It is possible to have multiple swap files or swap partitions, but generally one should be enough.

      We can see if the system has any configured swap by typing:

      If you don’t get back any output, this means your system does not have swap space available currently.

      You can verify that there is no active swap using the free utility:

      Output

      total used free shared buff/cache available Mem: 981Mi 122Mi 647Mi 0.0Ki 211Mi 714Mi Swap: 0B 0B 0B

      As you can see in the Swap row of the output, no swap is active on the system.

      Step 2 – Checking Available Space on the Hard Drive Partition

      Before we create our swap file, we’ll check our current disk usage to make sure we have enough space. Do this by entering:

      Output

      Filesystem Size Used Avail Use% Mounted on udev 474M 0 474M 0% /dev tmpfs 99M 932K 98M 1% /run /dev/vda1 25G 1.4G 23G 7% / tmpfs 491M 0 491M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 491M 0 491M 0% /sys/fs/cgroup /dev/vda15 105M 3.9M 101M 4% /boot/efi /dev/loop0 55M 55M 0 100% /snap/core18/1705 /dev/loop1 69M 69M 0 100% /snap/lxd/14804 /dev/loop2 28M 28M 0 100% /snap/snapd/7264 tmpfs 99M 0 99M 0% /run/user/1000

      The device with / in the Mounted on column is our disk in this case. We have plenty of space available in this example (only 1.4G used). Your usage will probably be different.

      Although there are many opinions about the appropriate size of a swap space, it really depends on your personal preferences and your application requirements. Generally, an amount equal to or double the amount of RAM on your system is a good starting point. Another good rule of thumb is that anything over 4G of swap is probably unnecessary if you are just using it as a RAM fallback.

      Step 3 – Creating a Swap File

      Now that we know our available hard drive space, we can create a swap file on our filesystem. We will allocate a file of the size that we want called swapfile in our root (/) directory.

      The best way of creating a swap file is with the fallocate program. This command instantly creates a file of the specified size.

      Since the server in our example has 1G of RAM, we will create a 1G file in this guide. Adjust this to meet the needs of your own server:

      • sudo fallocate -l 1G /swapfile

      We can verify that the correct amount of space was reserved by typing:

      • -rw-r--r-- 1 root root 1.0G Apr 25 11:14 /swapfile

      Our file has been created with the correct amount of space set aside.

      Step 4 – Enabling the Swap File

      Now that we have a file of the correct size available, we need to actually turn this into swap space.

      First, we need to lock down the permissions of the file so that only users with root privileges can read the contents. This prevents normal users from being able to access the file, which would have significant security implications.

      Make the file only accessible to root by typing:

      Verify the permissions change by typing:

      Output

      -rw------- 1 root root 1.0G Apr 25 11:14 /swapfile

      As you can see, only the root user has the read and write flags enabled.

      We can now mark the file as swap space by typing:

      Output

      Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes) no label, UUID=6e965805-2ab9-450f-aed6-577e74089dbf

      After marking the file, we can enable the swap file, allowing our system to start using it:

      Verify that the swap is available by typing:

      Output

      NAME TYPE SIZE USED PRIO /swapfile file 1024M 0B -2

      We can check the output of the free utility again to corroborate our findings:

      Output

      total used free shared buff/cache available Mem: 981Mi 123Mi 644Mi 0.0Ki 213Mi 714Mi Swap: 1.0Gi 0B 1.0Gi

      Our swap has been set up successfully and our operating system will begin to use it as necessary.

      Step 5 – Making the Swap File Permanent

      Our recent changes have enabled the swap file for the current session. However, if we reboot, the server will not retain the swap settings automatically. We can change this by adding the swap file to our /etc/fstab file.

      Back up the /etc/fstab file in case anything goes wrong:

      • sudo cp /etc/fstab /etc/fstab.bak

      Add the swap file information to the end of your /etc/fstab file by typing:

      • echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

      Next we’ll review some settings we can update to tune our swap space.

      Step 6 – Tuning your Swap Settings

      There are a few options that you can configure that will have an impact on your system’s performance when dealing with swap.

      Adjusting the Swappiness Property

      The swappiness parameter configures how often your system swaps data out of RAM to the swap space. This is a value between 0 and 100 that represents a percentage.

      With values close to zero, the kernel will not swap data to the disk unless absolutely necessary. Remember, interactions with the swap file are “expensive” in that they take a lot longer than interactions with RAM and they can cause a significant reduction in performance. Telling the system not to rely on the swap much will generally make your system faster.

      Values that are closer to 100 will try to put more data into swap in an effort to keep more RAM space free. Depending on your applications’ memory profile or what you are using your server for, this might be better in some cases.

      We can see the current swappiness value by typing:

      • cat /proc/sys/vm/swappiness

      Output

      60

      For a Desktop, a swappiness setting of 60 is not a bad value. For a server, you might want to move it closer to 0.

      We can set the swappiness to a different value by using the sysctl command.

      For instance, to set the swappiness to 10, we could type:

      • sudo sysctl vm.swappiness=10

      Output

      vm.swappiness = 10

      This setting will persist until the next reboot. We can set this value automatically at restart by adding the line to our /etc/sysctl.conf file:

      • sudo nano /etc/sysctl.conf

      At the bottom, you can add:

      /etc/sysctl.conf

      vm.swappiness=10
      

      Save and close the file when you are finished.

      Adjusting the Cache Pressure Setting

      Another related value that you might want to modify is the vfs_cache_pressure. This setting configures how much the system will choose to cache inode and dentry information over other data.

      Basically, this is access data about the filesystem. This is generally very costly to look up and very frequently requested, so it’s an excellent thing for your system to cache. You can see the current value by querying the proc filesystem again:

      • cat /proc/sys/vm/vfs_cache_pressure

      Output

      100

      As it is currently configured, our system removes inode information from the cache too quickly. We can set this to a more conservative setting like 50 by typing:

      • sudo sysctl vm.vfs_cache_pressure=50

      Output

      vm.vfs_cache_pressure = 50

      Again, this is only valid for our current session. We can change that by adding it to our configuration file like we did with our swappiness setting:

      • sudo nano /etc/sysctl.conf

      At the bottom, add the line that specifies your new value:

      /etc/sysctl.conf

      vm.vfs_cache_pressure=50
      

      Save and close the file when you are finished.

      Conclusion

      Following the steps in this guide will give you some breathing room in cases that would otherwise lead to out-of-memory exceptions. Swap space can be incredibly useful in avoiding some of these common problems.

      If you are running into OOM (out of memory) errors, or if you find that your system is unable to use the applications you need, the best solution is to optimize your application configurations or upgrade your server.



      Source link

      How To Add and Delete Users on CentOS 8


      Introduction

      When you first start using a fresh Linux server, adding and removing users is often one of first things you’ll need to do. In this guide, we will cover how to create user accounts, assign sudo privileges, and delete users on a CentOS 8 server.

      Prerequisites

      This tutorial assumes you are logged into a CentOS 8 server with a non-root sudo-enabled user. If you are logged in as root instead, you can drop the sudo portion of all the following commands, but they will work either way.

      Adding Users

      Throughout this tutorial we will be working with the user sammy. Please susbtitute with the username of your choice.

      You can add a new user by typing:

      Next, you’ll need to give your user a password so that they can log in. To do so, use the passwd command:

      You will be prompted to type in the password twice to confirm it. Now your new user is set up and ready for use!

      Note: if your SSH server disallows password-based authentication, you will not yet be able to connect with your new username. Details on setting up key-based SSH authentication for the new user can be found in step 5 of Initial Server Setup with CentOS 8.

      Granting Sudo Privileges to a User

      If your new user should have the ability to execute commands with root (administrative) privileges, you will need to give them access to sudo.

      We can do this by adding the user to the wheel group (which gives sudo access to all of its members by default).

      Use the usermod command to add your user to the wheel group:

      • sudo usermod -aG wheel sammy wheel

      Now your new user is able to execute commands with administrative privileges. To do so, append sudo ahead of the command that you want to execute as an administrator:

      You will be prompted to enter the password of the your user account (not the root password). Once the correct password has been submitted, the command you entered will be executed with root privileges.

      Managing Users with Sudo Privileges

      While you can add and remove users from a group with usermod, the command doesn’t have a way to show which users are members of a group.

      To see which users are part of the wheel group (and thus have sudo privileges), you can use the lid command. lid is normally used to show which groups a user belongs to, but with the -g flag, you can reverse it and show which users belong in a group:

      Output

      centos(uid=1000) sammy(uid=1001)

      The output will show you the usernames and UIDs that are associated with the group. This is a good way of confirming that your previous commands were successful, and that the user has the privileges that they need.

      Deleting Users

      If you have a user account that you no longer need, it’s best to delete it.

      To delete the user without deleting any of their files, use the userdel command:

      If you want to delete the user’s home directory along with their account, add the -r flag to userdel:

      With either command, the user will automatically be removed from any groups that they were added to, including the wheel group if applicable. If you later add another user with the same name, they will have to be added to the wheel group again to gain sudo access.

      Conclusion

      You should now have a good grasp on how to add and remove users from your CentOS 8 server. Effective user management will allow you to separate users and give them only the access that is needed for them to do their job.

      You can now move on to configuring your CentOS 8 server for whatever software you need, such as a LAMP or LEMP web stack.



      Source link