prompt: We are currently solving the following issue within our repository. Here is the issue text:
  --- BEGIN ISSUE ---
  Improve our test coverage
  ### Feature description
  
  Many of our existing algorithm files have little to no unit testing. This is problematic because this can easily let bugs slip through. We want some assurance that the code we currently have is correct and functional. We welcome all contributors to open PRs to help us add tests to our codebase.
  
  ### How to find low-coverage files
  
  Go to the Actions tab in this repository and find the most recent **build** workflow run. Open the logs under "Run Tests" and scroll down until you find the section on code coverage:
  ```
  ---------- coverage: platform linux, python 3.12.0-final-0 -----------
  Name                                                                          Stmts   Miss  Cover   Missing
  -----------------------------------------------------------------------------------------------------------
  quantum/q_fourier_transform.py                                                   30     30     0%   14-93
  scripts/validate_solutions.py                                                    54     54     0%   2-94
  strings/min_cost_string_conversion.py                                            78     75     4%   20-57, 61-75, 79-129
  ...
  ```
  The "Cover" column tells you what percentage of the lines in that file are covered by tests. We want to increase this percentage for existing files. Find a file with low coverage percentage that you wish to write tests for, add doctests for each function, and open a PR with your changes. You do not need to have a perfect coverage percentage, but all functions should have doctests.
  
  Some files will naturally be hard to write tests for. For example, the file may be poorly written because they lack any functions. Other files might be how-tos, meaning they simply demonstrate how to use an existing library's functions rather than implementing the algorithm themselves. Ignore these kinds of files, as they will need to be rewritten eventually. Furthermore, ignore files in the `web_programming` and `project_euler` directories. Web programming files are inherently hard to test and Project Euler files have their own validation workflow, so don't worry about their test coverage.
  
  _**When you open your PR, put "Contributes to #9943" in the PR description.**_ Do not use the word "fixes", "resolves", or "closes". This issue is an ongoing one, and your PR will not single-handedly resolve this issue.
  
  ### How to add doctests
  
  A doctest is a unit test that is contained within the documentation comment (docstring) for a function. Here is an example of what doctests look like within a docstring:
  ```py
  def add(a: int, b: int) -> int:
      """
      Adds two non-negative numbers.
      >>> add(1, 1)
      2
      >>> add(2, 5)
      7
      >>> add(1, 0)
      1
      >>> add(-1, -1)
      Traceback (most recent last):
      ...
      ValueError: Numbers must be non-negative
      """
  ```
  For every function in the file you choose, you should write doctests like the ones shown above in its docstring. If a function doesn't have a docstring, add one. Your doctests should be comprehensive but not excessive: you should write just enough tests to cover all basic cases as well as all edge cases (e.g., negative numbers, empty lists, etc).
  
  Do not simply run a function on some example inputs and put its output as the expected output for a doctest. This assumes that the function is implemented correctly when it might not be. Verify independently that your doctests and their expected outputs are correct. **Your PR will not be merged if it has failing tests.** If you happen to discover a bug while writing doctests, please fix it.
  
  _**Please read our [contributing guidelines](https://github.com/TheAlgorithms/Python/blob/master/CONTRIBUTING.md) before you contribute.**_
  
  --- END ISSUE ---
  
  Below are some code segments, each from a relevant file. One or more of these files may contain bugs.
  --- BEGIN FILES ---
  Path: `dynamic_programming/minimum_partition.py`
  Content:
  ```
  1 """
  2 Partition a set into two subsets such that the difference of subset sums is minimum
  3 """
  4 
  5 
  6 def find_min(arr):
  7     n = len(arr)
  8     s = sum(arr)
  9 
  10     dp = [[False for x in range(s + 1)] for y in range(n + 1)]
  11 
  12     for i in range(1, n + 1):
  13         dp[i][0] = True
  14 
  15     for i in range(1, s + 1):
  16         dp[0][i] = False
  17 
  18     for i in range(1, n + 1):
  19         for j in range(1, s + 1):
  20             dp[i][j] = dp[i][j - 1]
  21 
  22             if arr[i - 1] <= j:
  23                 dp[i][j] = dp[i][j] or dp[i - 1][j - arr[i - 1]]
  24 
  25     for j in range(int(s / 2), -1, -1):
  26         if dp[n][j] is True:
  27             diff = s - 2 * j
  28             break
  29 
  30     return diff
  31
  ```
  --- END FILES ---
  
  Please first localize the bug based on the issue statement, and then generate a patch according to the `git diff` format fenced by three backticks.
  
  Here is an example:
  
  ```diff
  diff --git a/examples/server_async.py b/examples/server_async.py
  --- a/examples/server_async.py
  +++ b/examples/server_async.py
  @@ -313,4 +313,4 @@
   
   
   if __name__ == "__main__":
  -    asyncio.run(run_async_server("."), debug=True)
  +    asyncio.run(run_async_server(), debug=True)
  diff --git a/examples/server_sync.py b/examples/server_sync.py
  --- a/examples/server_sync.py
  +++ b/examples/server_sync.py
  @@ -313,5 +313,5 @@
   
   
   if __name__ == "__main__":
  -    server = run_sync_server(".")
  +    server = run_sync_server()
       server.shutdown()
  
  ```
  
golden_diff: diff --git a/dynamic_programming/minimum_partition.py b/dynamic_programming/minimum_partition.py
  --- a/dynamic_programming/minimum_partition.py
  +++ b/dynamic_programming/minimum_partition.py
  @@ -3,13 +3,25 @@
   """
   
   
  -def find_min(arr):
  +def find_min(arr: list[int]) -> int:
  +    """
  +    >>> find_min([1, 2, 3, 4, 5])
  +    1
  +    >>> find_min([5, 5, 5, 5, 5])
  +    5
  +    >>> find_min([5, 5, 5, 5])
  +    0
  +    >>> find_min([3])
  +    3
  +    >>> find_min([])
  +    0
  +    """
       n = len(arr)
       s = sum(arr)
   
       dp = [[False for x in range(s + 1)] for y in range(n + 1)]
   
  -    for i in range(1, n + 1):
  +    for i in range(n + 1):
           dp[i][0] = True
   
       for i in range(1, s + 1):
  @@ -17,7 +29,7 @@
   
       for i in range(1, n + 1):
           for j in range(1, s + 1):
  -            dp[i][j] = dp[i][j - 1]
  +            dp[i][j] = dp[i - 1][j]
   
               if arr[i - 1] <= j:
                   dp[i][j] = dp[i][j] or dp[i - 1][j - arr[i - 1]]
  @@ -28,3 +40,9 @@
               break
   
       return diff
  +
  +
  +if __name__ == "__main__":
  +    from doctest import testmod
  +
  +    testmod()
  
verification_info: {"golden_diff": "diff --git a/dynamic_programming/minimum_partition.py b/dynamic_programming/minimum_partition.py\n--- a/dynamic_programming/minimum_partition.py\n+++ b/dynamic_programming/minimum_partition.py\n@@ -3,13 +3,25 @@\n \"\"\"\n \n \n-def find_min(arr):\n+def find_min(arr: list[int]) -> int:\n+    \"\"\"\n+    >>> find_min([1, 2, 3, 4, 5])\n+    1\n+    >>> find_min([5, 5, 5, 5, 5])\n+    5\n+    >>> find_min([5, 5, 5, 5])\n+    0\n+    >>> find_min([3])\n+    3\n+    >>> find_min([])\n+    0\n+    \"\"\"\n     n = len(arr)\n     s = sum(arr)\n \n     dp = [[False for x in range(s + 1)] for y in range(n + 1)]\n \n-    for i in range(1, n + 1):\n+    for i in range(n + 1):\n         dp[i][0] = True\n \n     for i in range(1, s + 1):\n@@ -17,7 +29,7 @@\n \n     for i in range(1, n + 1):\n         for j in range(1, s + 1):\n-            dp[i][j] = dp[i][j - 1]\n+            dp[i][j] = dp[i - 1][j]\n \n             if arr[i - 1] <= j:\n                 dp[i][j] = dp[i][j] or dp[i - 1][j - arr[i - 1]]\n@@ -28,3 +40,9 @@\n             break\n \n     return diff\n+\n+\n+if __name__ == \"__main__\":\n+    from doctest import testmod\n+\n+    testmod()\n", "issue": "Improve our test coverage\n### Feature description\r\n\r\nMany of our existing algorithm files have little to no unit testing. This is problematic because this can easily let bugs slip through. We want some assurance that the code we currently have is correct and functional. We welcome all contributors to open PRs to help us add tests to our codebase.\r\n\r\n### How to find low-coverage files\r\n\r\nGo to the Actions tab in this repository and find the most recent **build** workflow run. Open the logs under \"Run Tests\" and scroll down until you find the section on code coverage:\r\n```\r\n---------- coverage: platform linux, python 3.12.0-final-0 -----------\r\nName                                                                          Stmts   Miss  Cover   Missing\r\n-----------------------------------------------------------------------------------------------------------\r\nquantum/q_fourier_transform.py                                                   30     30     0%   14-93\r\nscripts/validate_solutions.py                                                    54     54     0%   2-94\r\nstrings/min_cost_string_conversion.py                                            78     75     4%   20-57, 61-75, 79-129\r\n...\r\n```\r\nThe \"Cover\" column tells you what percentage of the lines in that file are covered by tests. We want to increase this percentage for existing files. Find a file with low coverage percentage that you wish to write tests for, add doctests for each function, and open a PR with your changes. You do not need to have a perfect coverage percentage, but all functions should have doctests.\r\n\r\nSome files will naturally be hard to write tests for. For example, the file may be poorly written because they lack any functions. Other files might be how-tos, meaning they simply demonstrate how to use an existing library's functions rather than implementing the algorithm themselves. Ignore these kinds of files, as they will need to be rewritten eventually. Furthermore, ignore files in the `web_programming` and `project_euler` directories. Web programming files are inherently hard to test and Project Euler files have their own validation workflow, so don't worry about their test coverage.\r\n\r\n_**When you open your PR, put \"Contributes to #9943\" in the PR description.**_ Do not use the word \"fixes\", \"resolves\", or \"closes\". This issue is an ongoing one, and your PR will not single-handedly resolve this issue.\r\n\r\n### How to add doctests\r\n\r\nA doctest is a unit test that is contained within the documentation comment (docstring) for a function. Here is an example of what doctests look like within a docstring:\r\n```py\r\ndef add(a: int, b: int) -> int:\r\n    \"\"\"\r\n    Adds two non-negative numbers.\r\n    >>> add(1, 1)\r\n    2\r\n    >>> add(2, 5)\r\n    7\r\n    >>> add(1, 0)\r\n    1\r\n    >>> add(-1, -1)\r\n    Traceback (most recent last):\r\n    ...\r\n    ValueError: Numbers must be non-negative\r\n    \"\"\"\r\n```\r\nFor every function in the file you choose, you should write doctests like the ones shown above in its docstring. If a function doesn't have a docstring, add one. Your doctests should be comprehensive but not excessive: you should write just enough tests to cover all basic cases as well as all edge cases (e.g., negative numbers, empty lists, etc).\r\n\r\nDo not simply run a function on some example inputs and put its output as the expected output for a doctest. This assumes that the function is implemented correctly when it might not be. Verify independently that your doctests and their expected outputs are correct. **Your PR will not be merged if it has failing tests.** If you happen to discover a bug while writing doctests, please fix it.\r\n\r\n_**Please read our [contributing guidelines](https://github.com/TheAlgorithms/Python/blob/master/CONTRIBUTING.md) before you contribute.**_\n", "before_files": [{"content": "\"\"\"\nPartition a set into two subsets such that the difference of subset sums is minimum\n\"\"\"\n\n\ndef find_min(arr):\n    n = len(arr)\n    s = sum(arr)\n\n    dp = [[False for x in range(s + 1)] for y in range(n + 1)]\n\n    for i in range(1, n + 1):\n        dp[i][0] = True\n\n    for i in range(1, s + 1):\n        dp[0][i] = False\n\n    for i in range(1, n + 1):\n        for j in range(1, s + 1):\n            dp[i][j] = dp[i][j - 1]\n\n            if arr[i - 1] <= j:\n                dp[i][j] = dp[i][j] or dp[i - 1][j - arr[i - 1]]\n\n    for j in range(int(s / 2), -1, -1):\n        if dp[n][j] is True:\n            diff = s - 2 * j\n            break\n\n    return diff\n", "path": "dynamic_programming/minimum_partition.py"}], "after_files": [{"content": "\"\"\"\nPartition a set into two subsets such that the difference of subset sums is minimum\n\"\"\"\n\n\ndef find_min(arr: list[int]) -> int:\n    \"\"\"\n    >>> find_min([1, 2, 3, 4, 5])\n    1\n    >>> find_min([5, 5, 5, 5, 5])\n    5\n    >>> find_min([5, 5, 5, 5])\n    0\n    >>> find_min([3])\n    3\n    >>> find_min([])\n    0\n    \"\"\"\n    n = len(arr)\n    s = sum(arr)\n\n    dp = [[False for x in range(s + 1)] for y in range(n + 1)]\n\n    for i in range(n + 1):\n        dp[i][0] = True\n\n    for i in range(1, s + 1):\n        dp[0][i] = False\n\n    for i in range(1, n + 1):\n        for j in range(1, s + 1):\n            dp[i][j] = dp[i - 1][j]\n\n            if arr[i - 1] <= j:\n                dp[i][j] = dp[i][j] or dp[i - 1][j - arr[i - 1]]\n\n    for j in range(int(s / 2), -1, -1):\n        if dp[n][j] is True:\n            diff = s - 2 * j\n            break\n\n    return diff\n\n\nif __name__ == \"__main__\":\n    from doctest import testmod\n\n    testmod()\n", "path": "dynamic_programming/minimum_partition.py"}]}