update some bs

+ readme
+ some change in the bash script using ports
This commit is contained in:
2025-08-17 15:43:11 +02:00
parent 734ec1dc73
commit 9532213adf
3 changed files with 169 additions and 72 deletions

175
readme.md
View File

@@ -1,20 +1,25 @@
## under construction
# QPP - Quick Problem Platfrom
### Like LeetCode
This is a lightweight, LeetCode-inspired problem-solving platform. You can run the server locally, contribute problems, and write unit tests.
but more lightweight
---
run the bash script to start the server.
## Getting Started
if you want to contribute write tests like this:
Run the provided bash/_batch_ script to start the server.
### FileStructure:
---
In /problems/ create a folder named after the problem.
## File Structure for Problems
In this folder create ```manifest.json, test.py, description.md```
Create a folder inside `/problems/` named after your problem. Each folder **must** contain:
* `manifest.json` # Dont worry you can change the info anytime to reload
* `test.py`
* `description.md`
**Example `manifest.json`:**
**Manifest.JSON needs to exsist and _needs_ to look like this:**
```json
{
"title": "Title of the Problem",
@@ -23,46 +28,138 @@ In this folder create ```manifest.json, test.py, description.md```
"difficulty": "easy || medium || hard",
"test_code": "problems/problempath/test.py"
}
```
I do know it might be a bit tedious but this is required and its the easiest way.
```
#### After you've decided on how you would name / write your Test write it like this:
> This structure is mandatory but ensures the easiest workflow.
- It is important to note that you _CAN_ write the Code the User is expected to write firstly. **BUT** after writing the UnitTest and it passing, comment out the written code.
---
It is supposed to look something like this (/sortlist/):
## Writing Problem Descriptions
* Use **simple and easy-to-understand language**. Avoid overly technical explanations.
* Syntax:
* Normal Markdown
* Start headings with `##` (looks cleaner than `#`)
* Include cross-links to resources, e.g., [W3Schools](https://www.w3schools.com/) or [Python Docs](https://docs.python.org/3/)
* Good formatting is always appreciated
---
## Developing & Running Locally
To run the backend during development:
```bash
python -m flask --app ./src/app.py --host=0.0.0.0 --port=5000
```
For production testing:
**Linux:**
```bash
python -m gunicorn -w 4 -b 0.0.0.0:8000 src.app:app
```
**Windows:**
```bat
:: Create database folder if missing
md .\src\database
python -m waitress --listen=0.0.0.0:8000 src.app:app
```
> Ensure all required packages are installed via `requirements.txt`. Python is versatile enough for this small backend.
---
### Migrating Legacy Code
When removing or refactoring legacy code:
1. Check if the code is used anywhere; if critical, branch into a testing branch first.
2. Ensure essential functionality is preserved.
---
## Committing Changes
* Ensure your editor uses **LF** line endings (`\n`) instead of CRLF.
* To automatically fix CRLF on commit:
```bash
git config core.autocrlf input
git add --renormalize .
git commit -m "Major Change"
```
* Recommended workflow:
1. Fork
2. Make changes
3. Submit a PR
4. Review & merge
> Using WSL with VS Code for development is recommended for consistent line endings on Windows.
---
## Writing Unit Tests
Follow this convention when writing unittests. **Implement the function first, then write tests.**
### Example: Phone Number Validation
**Function (`phone_validation.py`):**
```python
import re
def is_valid_phone_number(phone_number: str) -> bool:
"""Return True if phone_number matches '123-456-7890' format."""
return bool(re.search(r"^(\d{3}-){2}\d{4}$", phone_number))
```
**Unit Test (`test_phone_validation.py`):**
```python
"""
@TESTSAMPLE.PY / NAME THIS "test.py" in your actual project
"""
import unittest
from phone_validation import is_valid_phone_number
" )) First Point from the List "
# def sortlist(lst = [4,3,2,1]) -> list:
# return sorted(lst)
class TestPhoneNumberRegex(unittest.TestCase):
")) This is a 'easy' Test, if you want you can write more defined ones."
class TestSolution(unittest.TestCase):
def test_sort(self):
self.x = []
self.assertEqual(sortlist(self.x), sorted(self.x)) # pyright: ignore[reportUndefinedVariable] <- This is only here so that pyright doesnt complain ; NOT NECCESARY!
def test_if_valid(self):
test_cases = [
("123-456-7890", True),
("111-222-3333", True),
("abc-def-ghij", False),
("1234567890", False),
("123-45-67890", False),
("12-3456-7890", False),
("", False),
]
print("\nPHONE NUMBER VALIDATION TEST RESULTS")
for phone, expected in test_cases:
try:
actual = is_valid_phone_number(phone)
status = "✓ PASS" if actual == expected else "✗ FAIL"
print(f"{status} | Input: '{phone}' -> Got: {actual} | Expected: {expected}")
self.assertEqual(actual, expected)
except Exception as e:
print(f"✗ ERROR | Input: '{phone}' -> Exception: {e}")
raise
if __name__ == "__main__":
unittest.main()
"""
PLEASE WRITE TEST ACCORDING TO
CONVENTION IN NEW TEST
@regex-phonenumber/test.py
"""
unittest.main(verbosity=2)
```
#### Writing the description:
**Please** by _God_ write simple and easy to understand terms. If you write like Einstein noone is going to understand you.
### ✅ Unit Test Guidelines
- Syntax:
- Normal Markdown.
- Start with "##" instead of "#" ; "##" looks better
- Use CrossLinks ( something like [W3](https://www.w3schools.com/), or the [PyDocs](https://docs.python.org/3/))
- Good Formatting is always appreciated
1. **Class Naming:** `Test<FunctionOrModuleName>`
2. **Method Naming:** `test_<what_is_being_tested>`
3. **Use tuples** `(input, expected_output)` for test cases
4. Include **edge cases** (empty strings, wrong formats)
5. **Print results** clearly for easier debugging
6. **Catch exceptions** and display failing input before raising

View File

@@ -21,5 +21,5 @@ export FLASK_ENV=production
# Run with Gunicorn
echo "Starting Flask app with Gunicorn..."
exec gunicorn -w 4 -b 0.0.0.0:5000 src.app:app
exec gunicorn -w 4 -b 0.0.0.0:8000 src.app:app

View File

@@ -1,33 +1,33 @@
import re
import unittest
## def is_valid_phone_number(phone_number : str):
## return bool(re.search(r"^(\d{3}-){2}\d{4}$", phone_number))
import unittest
class TestPhoneNumberRegex(unittest.TestCase):
def test_if_valid(self):
test_cases = [
("123-456-7890", True), # Valid format
("111-222-3333", True), # Another valid format
("abc-def-ghij", False), # Letters instead of digits
("1234567890", False), # Missing dashes
("123-45-67890", False), # Wrong grouping
("12-3456-7890", False), # Wrong grouping again
("", False), # Empty string
]
print("\nPHONE NUMBER VALIDATION TEST RESULTS")
for phone, expected in test_cases:
try:
actual = is_valid_phone_number(phone) # pyright: ignore[reportUndefinedVariable]
status = "✓ PASS" if actual == expected else "✗ FAIL"
print(f"{status} | Input: '{phone}' -> Got: {actual} | Expected: {expected}")
self.assertEqual(actual, expected)
except Exception as e:
print(f"✗ ERROR | Input: '{phone}' -> Exception: {e}")
raise
if __name__ == "__main__":
import re
import unittest
## def is_valid_phone_number(phone_number : str):
## return bool(re.search(r"^(\d{3}-){2}\d{4}$", phone_number))
import unittest
class TestPhoneNumberRegex(unittest.TestCase):
def test_if_valid(self):
test_cases = [
("123-456-7890", True), # Valid format
("111-222-3333", True), # Another valid format
("abc-def-ghij", False), # Letters instead of digits
("1234567890", False), # Missing dashes
("123-45-67890", False), # Wrong grouping
("12-3456-7890", False), # Wrong grouping again
("", False), # Empty string
]
print("\nPHONE NUMBER VALIDATION TEST RESULTS")
for phone, expected in test_cases:
try:
actual = is_valid_phone_number(phone) # pyright: ignore[reportUndefinedVariable]
status = "✓ PASS" if actual == expected else "✗ FAIL"
print(f"{status} | Input: '{phone}' -> Got: {actual} | Expected: {expected}")
self.assertEqual(actual, expected)
except Exception as e:
print(f"✗ ERROR | Input: '{phone}' -> Exception: {e}")
raise
if __name__ == "__main__":
unittest.main(verbosity=2)