[TOC]
# My Testing Method on Pynecone 0.1.29 for pynecone-examples

Before testing, I uninstall my Anaconda and then install it again. In the clean anaconda, I create the first new environment from the conda.

conda create -n pc129py311 python=3.11
conda activate pc129py311
pip install pynecone==0.1.29

And then, I start to test each example in this virtual environment `pc129py311`.
This action is to make sure I have a clean environment to test.

## Quick explanation of one-line command
I use the following one-line to test each example

pip install -r requirements.txt && rm -f pynecone.db && rm -rf .web && for i in $(find ./ | grep __pycache__$); do rm -rf $i; done && echo -e "\033[1;92mMy Testing Environment\033[0m" && echo -e "\t"OS $(uname) $(uname -r) && echo -e "\t"Pynecone $(pc version) && echo -e "\t"$(python --version) && echo -e "\t"Node $(node --version) && echo -e "\t"Bun $(~/.bun/bin/bun --version) && pc init && pc run --loglevel=debug

I you want to understand what the above has done, you can refer to the following clear bash script, which is the same as the above one-line.

#!/bin/bash
# install python packages of this example
pip install -r requirements.txt
# clean all the built files
rm -f pynecone.db
rm -rf .web
for i in $(find ./ | grep __pycache__$); do rm -rf $i; done
# Display current testing environment
echo -e "\033[1;92mMy Testing Environment\033[0m"
echo -e "\t"OS $(uname) $(uname -r)
echo -e "\t"Pynecone $(pc version)
echo -e "\t"$(python --version)
echo -e "\t"Node $(node --version)
echo -e "\t"Bun $(~/.bun/bin/bun --version)
# pynecone initial and run with debug level
pc init
pc run --loglevel=debug

## Explanation for the detailed script
For the above script, the following will describe why we do that.
### 1. Install python packages of this example
Each example in `pynecone-io/pynecone-examples.git` has the requirements.txt, it is the best way to make the same environment. So we can often install it.
### 2. Clean all the built files
We need to clean all data to start writing the correct steps to reproduce our bug. If some data is not clean, the steps may not copy the bug again.

rm -f pynecone.db

**Purpose:** Some apps will record data in SQLite; we need to clean it.

When the example saves some data into SQLite, you need to clean it, or your application cannot run from a clean environment again. If you keep SQLite there and don't clean it, you cannot reproduce your bug.

Then you can not write your correct steps to reproduce the bug.
So that is why we need to do it.

rm -rf .web

**Purpose:** clean all frontend JS code

Because Pynecone auto-generates the frontend JS code through .py, we clean it to ensure every test will get the latest auto-generated code.

Why do we need to clean and auto-generate again?
For example, If you call `pc run`, it will get `api_url` from the file `pcconfig.py` and write it into index.js in the .web. Think about that if the running initialized process has some bug.

for i in $(find ./ | grep __pycache__$); do rm -rf $i; done

**Purpose:** clean all built compiled file of .py

The only purpose of `__pycache__` is to put compiled byte code of CPython.

First time to auto-compiled, and next time can use it quickly.
But we must ensure all compiled code matches our latest Python source code. So we need to clean it. It only costs a little performance but makes the testing quality better.

### 3. Display current testing environment

echo -e "\033[1;92mMy Testing Environment\033[0m"
echo -e "\t"OS $(uname) $(uname -r)
echo -e "\t"Pynecone $(pc version)
echo -e "\t"$(python --version)
echo -e "\t"Node $(node --version)
echo -e "\t"Bun $(~/.bun/bin/bun --version)

When the pynecone app run, we care about
- The operation system on your PC.
- Pynecone version
- Python version
- NodeJS version
- Bun-runtime version

**Why we need to show these five information ?**
The relationship of this five things can like the following.

OS
 |
Python
 |
Pynecone --+- frontend (Bun+NodeJS) [Layout of pc app] ---| 
           |                                              +--- PC app
           +- backend (Python) [State of pc app]----------|

**Bun + NodeJS**
Bun-runtime and NodeJS will run in the localhost frontend server. Bun-runtime will use port 3000 by default.

**Pynecone**
The Pynecone will run the current version of Python to generate the JS source code to the frontend server, and the Python in the backend can work well with the frontend server.

**Python**
The running python runs our OS and uses something like process, asyncio or multiprocess. python is running as a backend server. It uses FastAPI to communicate with the front-end server.

**OS**
We cannot assume the same Python code can have the 100% same result in all OS, So the better way is to show OS and Python's version too.

### NOTICE
>*The detailed description of the above sections maybe wrong because I still do not understand the core part of Pynecone. You can add comments on this document to help this document well. Then I will correct this document.*