Forem: Oleksii Lytvynov

The Strange 'else' in Python

Oleksii Lytvynov — Wed, 01 Jan 2025 18:57:03 +0000

Else in Conditional Statements

We’ve all written conditional statements and have probably used the complete if-elif-else structure at least once.
For example, when creating a web driver instance for the required browser:

browser = get_browser()
if browser == 'chrome':
    driver = Chrome()
elif browser == 'firefox':
    driver = Firefox()
else:
    raise ValueError('Browser not supported')

This snippet supports testing with Chrome and Firefox, and raises an exception if an unsupported browser is provided.

A lesser-known fact is that Python supports the use of the else clause with loops and exception handling.

Else with Loops

Imagine we have a list of words, and we want to print them as long as they start with an uppercase letter. At the end, we want to check whether all words were processed and, if so, perform specific logic.

We might use a flag variable is_all_words_processed, setting it to False if we encounter an invalid word, then checking it outside the loop to execute the logic.

seasons = ['Winter', 'Spring', 'Summer', 'Autumn']
is_all_words_processed = True
for season in seasons:
    if not season.istitle():
        is_all_words_processed = False
        break
    print(season)

if is_all_words_processed:
    print('All seasons were processed')

Python allows us to avoid the additional variable by placing the logic when all words are valid into the else clause:

seasons = ['Winter', 'Spring', 'Summer', 'Autumn']
for season in seasons:
    if not season.istitle():
        break
    print(season)
else:
    print('All seasons were processed')

The else block will execute only if the loop completes naturally, without a break. If the loop is interrupted by break, the else clause will not run.
Here’s the same example rewritten with a while loop. With while, the else clause behaves in the same way:

seasons = ['Winter', 'Spring', 'Summer', 'Autumn']
index = 0
while index < len(seasons):
    if not seasons[index].istitle():
        break
    print(seasons[index])
    index += 1
else:
    print('All seasons were processed')

Else in Exception Handling

The else clause can also be used in exception handling. It must come after all except blocks. The code inside the else block will execute only if no exceptions are raised in the try block.

For example, let’s read a file containing numbers in two columns and print their quotient. We need to handle an invalid file name, while any other errors (e.g., converting a value to a number or division by zero) should cause the program to crash (we will not handle them).

file_name = 'input.dat'
try:
    f = open(file_name, 'r')
except FileNotFoundError:
    print('Incorrect file name')
else:
    for line in f:
        a, b = map(int, line.split())
        print(a / b)
    f.close()

In this example, the try block contains only the code that might raise the caught exception.
The official documentation suggests using the else block to avoid unintentionally catching exceptions raised by code outside the try block. Still, the use of else in exception handling might not feel intuitive.

Combining Else with Loops and Exception Handling

Here’s an question I posed at interviews.
Suppose we have a Driver class with a method find_element. The find_element method either returns an element or raises an ElementNotFoundException exception. In this example, it’s implemented to randomly return an element or raise an exception with equal probability.

Using basic Python syntax, implement a method smart_wait(self, locator: str, timeout: float, step: float) that checks for an element with the given locator every step seconds. If the element is found within timeout seconds, return; otherwise, raise an ElementNotFoundException exception.

from random import random


class Element:
    pass


class ElementNotFoundException(Exception):
    pass


class Driver:

    def __init__(self):
        pass

    def find_element(self, locator: str):
        print(f"Finding element: {locator}")
        if random() < 0.5:
            return Element()
        else:
            raise ElementNotFoundException

    def smart_wait(self, locator: str, timeout: float, step: float):
        raise NotImplementedError

Here’s one approach to implement this method:

Trying to find the element as long as the timeout hasn't elapsed.
If the element is found, exit the loop.
If the element isn’t found, wait for the step interval.
Raise an ElementNotFoundException if the timeout is exceeded. Here’s a straightforward implementation:

from time import sleep, monotonic
    def smart_wait(self, locator: str, timeout: float, step: float):
        start_time = monotonic()
        current_time = start_time
        while current_time - start_time < timeout:
            try:
                self.find_element(locator)
                break
            except ElementNotFoundException:
                sleep(step)
                current_time = monotonic()
        if current_time - start_time >= timeout:
            raise ElementNotFoundException

We could shorten the logic a bit by using return instead of break, but let's leave it as i for now.

In fact, this method is implemented in the WebDriverWait class of Selenium - until method:

POLL_FREQUENCY: float = 0.5  # How long to sleep in between calls to the method
IGNORED_EXCEPTIONS: Tuple[Type[Exception]] = (NoSuchElementException,)  # default to be ignored.
class WebDriverWait(Generic[D]):
    def __init__(
        self,
        driver: D,
        timeout: float,
        poll_frequency: float = POLL_FREQUENCY,
        ignored_exceptions: Optional[WaitExcTypes] = None,
    ):

    # ...

    def until(self, method: Callable[[D], Union[Literal[False], T]], message: str = "") -> T:
        """Calls the method provided with the driver as an argument until the \
        return value does not evaluate to ``False``.

        :param method: callable(WebDriver)
        :param message: optional message for :exc:`TimeoutException`
        :returns: the result of the last call to `method`
        :raises: :exc:`selenium.common.exceptions.TimeoutException` if timeout occurs
        """
        screen = None
        stacktrace = None

        end_time = time.monotonic() + self._timeout
        while True:
            try:
                value = method(self._driver)
                if value:
                    return value
            except self._ignored_exceptions as exc:
                screen = getattr(exc, "screen", None)
                stacktrace = getattr(exc, "stacktrace", None)
            if time.monotonic() > end_time:
                break
            time.sleep(self._poll)
        raise TimeoutException(message, screen, stacktrace)

Now, let’s rewrite this method using else for both exception handling and loops:

Exception could be raised only in line self.find_element(locator). Exit from loop should be performed in case when exception wasn't raised. So we could move break to else block.
Our method should raise exception if loop was exited not because of break. So we could move exception raising to else clause of the loop.
If you perform transformation 1 and 2 consequentially, you see that current time could be taken only in loop condition.

Completing these transformations, we obtain a method that uses the else statement for both exception handling and the loop:

from time import sleep, monotonic
    def smart_wait(self, locator: str, timeout: float, step: float):
        start_time = monotonic()
        while monotonic() - start_time < timeout:
            try:
                self.find_element(locator)
            except ElementNotFoundException:
                sleep(step)
            else:
                break
        else:
            raise ElementNotFoundException

What can I say... This is one of Python’s lesser-known features. Infrequent use might make it less intuitive to use in every scenario — it can lead to confusion. However, knowing it and applying it effectively when needed is undoubtedly worthwhile.

Happy New Year! 🎉🎄🎅

P.S. It was really scary 😱:
I write articles on my own but translate them using ChatGPT. For translation I removed all code snippets but ChatGPT restores them all 👻

No Country For \0 (Escaping Characters Issues in ReportPortal)

Oleksii Lytvynov — Sun, 01 Dec 2024 17:35:00 +0000

This is another story that happened to me during the integration of tests with ReportPortal. ReportPortal allows uploading a test description stored in the test function’s docstring. This is pretty convenient: test cases are stored along with the scripts and are also published together with the results.
Let’s consider a few cases.

Test with plain docstrings

We can use plain text to describe what the test verifies:

def test_with_usual_docstrings():
    """Verify adding integer positive numbers

    First number is 3
    Second number is 5

    Result is 8
    """
    pass

This is the result we get on the test launch page in ReportPortal:

Empty lines are not displayed. But if you go to the test details page, the description will match the docstring:

Test with a docstrings having an indent in the first line and an empty line at the end

Docstrings in Python are described in PEP 257 – Docstring Conventions. According to it, any leading spaces in the first line and blank lines at the beginning and end of docstrings should be stripped by tools that creates documentation. This PEP includes a trim function that processes docstrings according to these rules. The pytest_reportportal library has the same trim_docstring function, taken from PEP without modifications.

If we use a docstring with an indent in the first line and an empty line at the end, they will not appear in ReportPortal:

def test_with_indent_in_first_line_and_empty_line_at_the_end_of_docstrings():
    """     Verify adding integer positive numbers

    First number is 4
    Second number is 6

    Result is 10

    """
    pass

Test with Markdown in docstrings

On the test details page, there are elements for editing test description. If we check the ReportPortal service-ui subproject responsible for rendering results on the web, we'll find components markdownEditor and markdownViewer.

Let’s create a test with Markdown in the docstring:

def test_with_markdown_in_docstrings():
    """**Verify adding float positive numbers**

    - First number is 1.73
    - Second number is 3.1
    ---
    Result is 4.83
    """

And the result in ReportPortal:

The first line is bolded, the second and third lines are listed as bullet points, and the result is separated by a horizontal line. On the web page, the formatting looks like this:

<div class="markdownViewer__markdown-viewer--GikqC mode-default">
    <p><strong>Verify adding float positive numbers</strong></p>
    <ul>
        <li>First number is 1.73</li>
        <li>Second number is 3.1</li>
    </ul>
    <hr>
    <p>Result is 4.83</p>
</div>

Test with \t and \n in docstrings

On the work, we often use strings with \t and \n as test strings. For example, something like this test:

def test_with_tab_and_newline_in_docstrings():
    """Verify application processes lines with \t and \n

    Add line "123\t456"
    Add line "789\n012"

    Printed lines equal to entered lines
    """
    pass

It doesn’t contain Markdown formatting, but the result is unexpected:

If we examine the markup, we find two code blocks (<code>):

<div class="markdownViewer__markdown-viewer--GikqC mode-default">
    <p>Verify application processes lines with          and</p>
    <pre><code>
        Add line "123       456"
        Add line "789
    </code></pre>
    <p>012"</p>
    <pre><code>Printed lines equal to entered lines</code></pre>
</div>

I then checked how the test description was sent in requests to ReportPortal (with and without special characters) using Wireshark and noted when the text was treated as a code block in Markdown. It turns out that we publish test with the following docstrings:

def test_with_tab_and_newline_in_docstrings():
    """Verify application processes lines with \t and \n

    Add line "123\t456"
    Add line "789
012"

    Printed lines equal to entered lines
    """
    pass

The issue with the indent lies in the trim_docstring function. It has a fragment that calculates the minimum indent in the docstring:

# Determine minimum indentation (first line doesn't count):
indent = sys.maxsize
for line in lines[1:]:
    stripped = line.lstrip()
    if stripped:
        indent = min(indent, len(line) - len(stripped))

Because of the newline character, the line 012" starts at the beginning of line, without an indent. Because of that, lines indented by four spaces are treated as code blocks.

By the way, this function was the first real production code where I saw the usage of the expandtabs string method. Initially, all tabs in the docstring are replaced with 8 spaces, then the string is split into lines:

lines = docstring.expandtabs().splitlines()

This issue can be fixed by escaping special characters:

def test_with_escaped_tab_and_newline_in_docstrings():
    """Verify application processes lines with \\t and \\n

    Add line "123\\t456"
    Add line "789\\n012"

    Printed lines equal to entered lines
    """
    pass

This gives us the expected result:

Test with \0 in docstrings

We also have test strings containing the \0 character. This caused a separate issue. When publishing results in such cases, the test launch is created, but the results are not published.

def test_with_slash_zero_in_docstrings():
    """Verify application processes lines with \0

    Add line with \0

    Printed lines equal to entered lines
    """
    pass

Again, checking the requests sent to ReportPortal, we see that the description field contains \0.

{
  "codeRef": "test_example.py:test_with_slash_zero_in_docstrings", 
  "description": "Verify application processes lines with \u0000\n\nAdd line with \u0000\n\nPrinted lines equal to entered lines", 
  "hasStats": true, 
  "name": "reportportal_escaping/test_example.py::test_with_slash_zero_in_docstrings", 
  "retry": false, 
  "retryOf": null, 
  "startTime": "1732975747211", 
  "testCaseId": "test_example.py:test_with_slash_zero_in_docstrings", 
  "type": "STEP", 
  "launchUuid": "5d3d8726-a58f-47de-bd85-1e21353a39a7", 
  "attributes": [], 
  "parameters": null
}

This issue seems doesn't belong to pytest_reportportal library but further down the stack. Perhaps it relates to request parsing or description field rendering on the web UI. I reported this problem in the pytest_reportportal library issue tracker (but maybe it should be moved to other subproject):
Test not published to Report Portal when docstring or parameter contains \0 #38

It also can be resolved by escaping the special character:

def test_with_escaped_slash_zero_in_docstrings():
    """Verify application processes lines with \\0

    Add line with \\0

    Printed lines equal to entered lines
    """
    pass

Test with \0 in a parameter value of parametrized test

A bigger problem arises if a parameterized test contains \0 in its parameter value.

import pytest

@pytest.mark.parametrize("line", ["abc\0", ])
def test_with_slash_zero_in_params(line):
    pass

Now in the request sent to create the test, the name field contains the escaped \0, but the testCaseId field contains the unescaped value.

{
  "name": "reportportal_escaping/test_example.py::test_with_slash_zero_in_params[abc\\x00]", 
  "testCaseId": "test_example.py:test_with_slash_zero_in_params[abc\u0000]"
}

This value cannot be escaped because the test requires it in its original form. As a workaround, we used a placeholder string for the parameter to indicate that the test string contains \0, and in the test itself, we replaced it with the actual value:

import pytest

@pytest.mark.parametrize("line", ["line with slash zero", ])
def test_with_slash_zero_in_params_workaround(line):
    if line == "line with slash zero":
        line = "abc\0"
    # test logic that uses variable line

ReportPortal is a widely used system for storing and processing test results. It offers advanced features like AI for result analysis. However, as we can see, even such system has shortcomings in rare use cases.

======================================================
[Update, 04 Dec 2024]

Contributor @HardNorth replied regarding this issue:

\0 is not a text character, it is strictly binary one. So strictly, that many libraries use it to check if data is binary or text. And RP wasn't supposed to work with binary data. Also in general we do not modify data on client side, except some special cases, so it's your responsibility to sanitize it.

Nevertheless, he fixed issue with non-publishing results in cases parameter value contains \0 (now it will be escaped, but only for parameters). It works starting from pytest-reportportal 5.4.7 👍

How ReportPortal "Made" Pytest Run Twice

Oleksii Lytvynov — Sun, 24 Nov 2024 19:44:15 +0000

A story of how a coincidence led to an unexpected behavior

We used to store our test run results in TestRail, but the time came to switch to something else. Interestingly, this isn’t the first time I’ve seen teams move away from TestRail recently. We considered various options for storing test results and eventually chose ReportPortal. Later we could talk about other options.

Integrating ReportPortal with Pytest

What surprised me - the integration was very simple. Unlike TestRail, which required writing an API client, publishing results to ReportPortal only requires specifying a few command-line options.

As you might guess from the title, the tests are written in Pytest. To publish results to ReportPortal, you just need to include the following options to the command that runs tests:

--reportportal: enable publishing
--rp-endpoint: the address of your ReportPortal server
--rp-api-key: your API key, generated in the User Profile section of ReportPortal
--rp-project: the name of the project where results should be published

For example, to run all tests and publish results to ReportPortal, we could use the following command:

pytest --reportportal --rp-endpoint=<RP_SERVER_ADDRESS> --rp-api-key=<RP_API_KEY> --rp-project=<PROJECT_NAME>

If we run tests with results publishing from a local machine, then we can define these parameters in pytest.ini file:

[pytest]
rp_endpoint=<RP_SERVER_ADDRESS>
rp_api_key=<RP_API_KEY>
rp_project=<PROJECT_NAME>

ReportPortal provides additional options as well. For example, --rp-rerun to overwrite results in an existing launch or --rp-launch-description to add a description to the test launch.

Note that command line options use hyphens(-), while pytest.ini parameters use underscores (_)

We publish results during the regression run when the final build is ready. Before that, regression could be run when tests were updated but without results being recorded. Regression is executed using GitLab CI/CD on dedicated machines.

Adding GitLab CI/CD Integration

Next we need to integrate result publishing with the GitLab CI/CD pipeline. Some runs would include results publishing, while others - not.

We add a dropdown variable to define whether publish results or not to the variables section:

variables:
  IS_RP_RUN:
    value: "no"
    options:
      - "no"
      - "yes"
    description: "Select 'yes' to publish results to Report Portal"

What we get on GitLab CI/CD UI:

GitLab CI/CD supports text variables and dropdowns. Dropdowns are useful for predefined options like enabling/disabling results publishing or selecting OS/browser to run tests on

By default, I choose value "no," as results should only be published for debugged tests. Depending on IS_RP_RUN value, we could pass or not pass options required for results publishing

The following conditional logic is added to the rules section of job:

  rules:
    - if: $IS_RP_RUN == "no"
      variables:
        RP_OPTIONS: ""
      when: always
    - if: $IS_RP_RUN == "yes"
      variables:
        RP_OPTIONS: '--reportportal --rp-endpoint=<RP_SERVER_ADDRESS> --rp-api-key=<RP_API_KEY> --rp-project=<PROJECT_NAME>'
      when: always
    - when: never

To the script section, we add command to run all tests:

pytest $RP_OPTIONS

Condition above will pass parameters for results publishing if we select "yes". If we don't want to publish results, an empty string will be passed.

In fact, with specified rules, pipeline will run on every commit. You could add one more variable for the build version. Then update the condition, so tests will run only when the version is specified. Or you could add condition "not to run pipeline on push events"

Let's run pipeline and see what we get in ReportPortal (Run ID is 23 because I ran it several time before).

We may need to pass other parameters for ReportPortal. So we create an additional text variable RP_ADDITIONAL_OPTIONS for them. It will have an empty string as a default value. In case when we run tests with the results publishing, we could enter there additional parameters.
Then the test run command will look like this:

pytest $RP_OPTIONS $RP_ADDITIONAL_OPTIONS

Now let's run tests again with the --rp-rerun option:

ReportPortal will successfully show that tests were rerun (Rerun mark appears on the same 23rd test launch):

If I want to add a description to the test launch, I should specify the option --rp-launch-description="Experimental run". But then the first problem will occur - the description will only indicate "Experimental and tests will not run at all.

The problem occurs because the expanded variable will be split by whitespace. Then the second part of the launch description (run") will be considered as the next parameter - test module, PyTest would like to run, but can't identify.
It is easy to fix that - just quote the variable:

pytest $RP_OPTIONS "$RP_ADDITIONAL_OPTIONS"

This is what we get now:

We are already approaching a "double" run:) It is not always necessary to run all tests. While we are debugging tests, we may want to run a separate module. To do this, we could add another variable MODULE_TO_RUN. We will specify the name of the module with tests in it. To run all tests, we will set test_*.py by default (let's say in this project tests are organized only by modules).
Then command to run tests will look like:

pytest $RP_OPTIONS "$RP_ADDITIONAL_OPTIONS" MODULE_TO_RUN

...And now double run

I should mention straight away that this issue is reproduced only on Linux

While I was testing run with additional ReportPortal options, everything was fine. Also, while I was adding integration with ReportPortal, I ran a module with only one test function. Now it's time to run tests as in real battle - all tests and without additional ReportPortal options.

Without reporting, the runtime of all tests was half an hour.
And I began to wait.
And wait.
And wait some more...

But half an hour had already passed. All the tests already appeared in ReportPortal (it publishes the results after each test function, so you see the results immediately). And now more tests began to appear in ReportPortal - more than there were in the project!

Let's look at the command we start tests this time, substituting all the values:

pytest --reportportal --rp-endpoint=<RP_SERVER_ADDRESS> --rp-api-key=<RP_API_KEY> --rp-project=<PROJECT_NAME> "" test_*.py

There seems to be nothing criminal. The only thing that can be alerting here is the empty string in quotes. Let's search for "pytest runs tests twice when contains quotes" and the second search result we get is an issue in the PyTest bug tracker:

Quotation marks in pytest command collects duplicate tests #7012

In the defect description we can see our case:

pytest --collect-only tests.py ""

If you read the details, you will find out that an empty string in quotes is interpreted by PyTest as LocalPath (.) and tests are also duplicated by the expression test_*.py.

This problem is not yet solved in PyTest. So how can we fix it on our side? We need some value in the RP_ADDITIONAL_OPTIONS variable.
Let's look at the list of ReportPortal options and choose some option with a default value. For example, --rp-mode=DEFAULT. Running the tests now, we will see that they are run only once.

ReportPortal offers many features for improving regression runs. Though I didn't find everything I wanted (for example grouping tests by modules and packages). Also, I faced one more interesting peculiarity of ReportPortal. I'll tell you about it some other time

Regular Expressions for Highlighting Comments in PyCharm

Oleksii Lytvynov — Sun, 17 Nov 2024 15:47:11 +0000

Students often ask why regular expressions are necessary. At first glance, their usefulness may not be obvious. In general, their purpose is working with text: searching and replacing.

For instance, I once needed to compare logs from two test runs. They were potentially identical, but each line began with timestamps that differed.
Using a regular expression to match the timestamps, I replaced those substrings with an empty string in Sublime (a feature likely available in any text editor). Afterward, I compared the two files in Meld — a handy tool for comparing files and directories that I frequently use.

PyCharm also supports searching and replacing text with regular expressions.

However, I’ll discuss another PyCharm feature that utilizes regular expressions: highlighting specific comments in code. The most common example is TODO comments.

But how does PyCharm know to highlight this text in a specific color? These settings can be customized, and that’s what we’ll explore.

Navigate to the menu:
File -> Settings... -> Editor -> TODO

Here, you'll find two predefined rules for highlighting comments: TODO and FIXME. Try it — FIXME uses the same highlighting rule as TODO.
The rule itself is defined by the regular expression: \btodo\b.*.

This pattern matches:

The word todo as a whole word (using \b to denote a word boundary)
Followed by any number of any characters (.*).

A word boundary (\b) is the edge between a \w character (letters, digits, or underscores) and a non-\w character.

In this menu, you can add your own rules. For example, let’s add a rule for "Not implemented".

Here, you can configure:

Pattern: a regular expression to match the text to highlight.
Icon: an icon to display in the TODO tool window.
Case sensitivity: whether the match is case-sensitive.
Default style: if unchecked, you can customize the highlighting style, otherwise default TODO style will be applied.
Custom style options:
- Font style (bold, italic)
- Text color
- Background color
- Error stripe color
- Decoration styles and their colors (underscored, bold underscored, underwaved, bordered, strikeout, dotted line).

Here’s what we’ve got:

And here’s how it appears in the TODO tool window: you can see the custom icon we selected, and the border color is more prominent. In this screenshot, I’ve also clicked the filters button to show that no filters are applied yet.

Let’s return to the TODO settings and add a filter for the "Not implemented" rule.

Now, in the TODO tool window, a new "Not implemented" filter appears in the list. When you select this filter, only "Not implemented" comments will display in the TODO tool window.

There’s one more option in the TODO comment settings we haven’t mentioned: "Treat indented text on the following lines as part of the same TODO".

This checkbox applies to all rules. If the line following a TODO comment contains an indented comment, the same rule will be applied to it.

As you can see, there’s no need to create overly complex regular expressions — simple ones will suffice. However, even in this context, they can make your work easier.
Do you use regular expressions often?

How to "serve" portfolio for test engineer

Oleksii Lytvynov — Sun, 10 Nov 2024 21:49:03 +0000

Introduction

Open to work, open to work, open to work...
Some people search for a job for a long time, while others are luckier. But luck alone won’t help much. According to statistics of Djinni service, there are 83,629 candidates and only 7,357 open positions. It's time for despair, right?

Common advice for increasing your chances includes crafting a solid CV and a well-organized LinkedIn profile. Another tip is to create a portfolio.

Will it be reviewed? When I hired employees, I checked GitHub links in CVs when there was one. In a large pool of candidates, a portfolio can be that "spark" that makes you stand out. Even if it doesn’t get reviewed, building a portfolio gives you valuable experience that will be useful in your work.
However, if you’re showing a portfolio, it’s worth preparing it well.

One candidate had a GitHub link in his CV. When I followed it, I found a couple of projects with several files containing "Hello, world!". It didn’t leave a good impression.

Portfolio for a Manual QA Specialist

I don’t really support the strict division between manual testers and automation specialists. While some companies have separate team of manual testers who write test cases and automation team to automate them, in my experience, such companies are rare. If a QA chooses only one stack, they limit their job options. I often worked on projects from requirements analysis to the final release.

The outcome of a manual tester’s work is a set of testing artifacts. They should be clear, have enough coverage, and be prioritized (don't forget to start with the happy path).

As a manual QA, you can create:

requirements to product (SRS) (keeping in mind quality criteria like completeness, clarity, consistency, necessity, feasibility, and testability)
test plan (you could follow IEEE 829, but concise documentation – one page – is better for a portfolio. In your day-to-day work include only necessary sections as well. Focus on a couple of features rather than trying to cover the entire product. Be sure to state what you’re testing and what you’re not).
checklists
test cases
test execution report and, if you’re lucky, a bug report
test report

What to test? For simplicity, you could choose well-known programs, like Notepad, MS Word, or Google Spreadsheets. If you’re applying to a company focused on mobile app development, it’s worth choosing a mobile app since mobile testing has its own peculiarities. You can also prepare testing documentation for different types of products (desktop, web, mobile).

You can also include examples of your work created during a hackathons or competitions (e.g., Dev Challenge).

Portfolio for a Test Automation Specialist

I’d recommend starting the same way as a manual tester. Decide what you will test – web, mobile, or API – or create automated tests for different types of projects. Your code quality as much important as quality for manual testing artifacts. A few automated scripts in a "blanket" style won’t reflect well on you. Instead, think about building a basic framework that’s well-structured, easy to expand, and follows code conventions. Potential employers may want to know your coding process – whether you pushed all changes to main or followed GitHub Flow. Don’t forget to write a good README – that’s likely to be the first file someone checks. Describe your framework’s structure and provide instructions for running tests.

In addition to automating different types of projects, you can try various approaches (examples for Python in parentheses):

Modular framework (pytest)
BDD (pytest-bdd, behave)
KDT (RobotFramework)

For writing automated tests, you can use the following resources:

Web UI

https://demo.guru99.com/Agile_Project/Agi_V1/ - very simple (basically login and a few actions)
https://www.globalsqa.com/angularJs-protractor/BankingProject/#/login - more interactive
https://www.saucedemo.com/ - test site from Sauce Labs
https://opensource-demo.orangehrmlive.com/web/index.php/auth/login - demo site from OrangeHRM. Once I was asked to automate several tests for this site as a job test assignment.

REST API

Where to Publish Your Portfolio

You can store your manual testing documentation on Google Drive (just remember to set view permissions). But it’s better to upload your work to GitHub. Even if you’re applying for a manual testing role, knowing Git will be an advantage.

Open Source

Some sources suggest asking a project manager for permission to share work samples from your previous projects. I doubt this is common practice due to NDAs. However, you don't need such permission if you write open-source code. Open-source projects also require tests, and you might fix a bug as well.

For example, one candidate showcased code she had written for open-source during working tasks.
While not many companies contribute to open-source projects, you can contribute personally and show examples of your code that were accepted in an open-source project. This is potentially more impressive than personal projects because it shows you worked with someone else’s code, followed code conventions, wrote tests, etc.

It’s best to focus on a single project and make several contributions to understand it better. Constantly switching between projects can reduce efficiency. For a given project, you can link to your accepted pull requests. For example, here are my accepted pull requests for the Faker library.

I wish you success in your job search if you’re currently looking. Try not to waste time. If you’re in between jobs, use this time wisely.