HTTP requester and unit Testing in sublime text

Introduction

Let's ensure we understand the foundational concepts before delving further into the subjects. Here is a brief introduction if you are unfamiliar with Sublime Text.

A cross-platform shareware source code editor is called Sublime Text. Numerous markup and programming languages are supported natively. Users can increase its capabilities by adding plugins, which are often developed and maintained by the community under free-software licences. A Python API is available in Sublime Text to help with plugins.   

This article explains the details of HTTP requester and unit Testing in sublime text in which we will talk about Sublime text, How to write test cases in Sublime text, and Sublime Http Requester.

Without further ado, let's get started.

How to write test cases in Sublime text

For Sublime Text, UnitTesting is a unittest framework. Unittest test cases are run locally and through Github Actions. Additionally, it supports sublime-color-scheme files and syntax test files for the new sublime-syntax format.

Note: Testing for Python 3.8 packages is now possible with Sublime Text 4 support. In spite of this, test coverage won't function until Package Control supports Python 3.8 package dependencies.

Preparation

1️⃣ Installing UnitTesting using Package Control is a prerequisite before conducting any testing.

2️⃣ Your package!

3️⃣ TestCases should be added to test*.py in the tests directory (configurable, see below). TestLoader then loads the test cases. discover.

Running Tests Locally

The command palette command UnitTesting can be used to start UnitTesting. Once the package name is entered and the enter key is pressed, a terminal should appear and the tests should start to run. Enter: to execute only the tests in the specified files. Should be a unix shell wildcard to match the file names; by default, test*.py is used.

To test the current package, use the command UnitTesting: Test Current Package. UnitTesting will first reload the current package before starting the tests.

The command UnitTesting: Test Current Package with Coverage can also be used to create test coverage reports using coverage. The coverage configurations are managed via the file.coveragerc. UnitTesting will disregard the tests directory if it is absent.

GitHub Actions

Put the following into your workflow as a basic.

name: test
on: [push, pull_request]
jobs:
  run-tests:
    strategy:
      fail-fast: false
      matrix:
        st-version: [3, 4]
        os: ["ubuntu-latest", "macOS-latest", "windows-latest"]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v2
      - uses: SublimeText/UnitTesting/actions/setup@v1
        with:
          sublime-text-version: ${{ matrix.st-version }}
      - uses: SublimeText/UnitTesting/actions/run-tests@v1
        with:
          coverage: true
      - uses: codecov/codecov-action@v3

Testing syntax_test files

name: test-syntax
on: [push, pull_request]
jobs:
  run-syntax-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: SublimeText/UnitTesting/actions/setup@v1
      - uses: SublimeText/UnitTesting/actions/run-syntax-tests@v1

Deferred testing

💁 You can run sublime commands from your test cases and give control to the sublime text runtime so that the execution can continue later by using the Deferrable testcase type of test writing. Allowing for the testing of asynchronous codes. Plugin UnitTest Harness served as the basis for the concept.

The test cases are created using DeferrableTestCase. They are run by the DeferringTextTestRunner, which also expects generators and standard test procedures. When a generator is the test function, it performs the following.

✔️ The runner will test the callable return value and evaluate if the provided object is callable. The generator is continued if the result is None; else, the default timeout of 4 seconds will be used to wait until the condition is satisfied. The yield statement can also be used to get the callable's outcome. The provided object could also be a dictionary with the format "condition": callable, timeout: timeout, where the timeout is specified in milliseconds. 

✔️ The generator will continue after x milliseconds if the object is an integer, such as x.

✔️ It would yield a job in the worker thread if yield AWAIT WORKER was used.

✔️ If not, one yield would be given to a task in the main thread.