Na początku platforma Fn oferowała kilka oficjalnie obsługiwanych FDK. W miarę upływu czasu, więcej FDK zostało wprowadzonych i obsługiwanych przez Fn CLI.

Cel FDK jest dość prosty - ukryć komunikację między Fn-to-function, a także zapewnić prosty w użyciu interfejs programowania. Celem jest uczynienie UX takim samym bez względu na język programowania, który programista wybierze do pisania funkcji bezserwerowych.

Testowanie

Fn CLI (zobacz fn test) zapewnia pierwszą barierę bezserwerowego testowania funkcji, tworząc konfigurowalny interfejs do wykonywania testów czarnoskrzynkowych . Spójrzmy na test.json:

{
    "tests": [
        {
            "input": {
                "body": {
                    "name": "Johnny"
                }
            },
            "output": {
                "body": {
                    "message": "Hello Johnny"
                }
            }
        },
        {
            "input": {
                "body": ""
            },
            "output": {
                "body": {
                    "message": "Hello World"
                }
            }
        }
    ]
}

O co tak naprawdę chodzi w tego typu testach? fn testudostępnia dwa tryby przeprowadzania tych testów: lokalny i zdalny. Kluczowa różnica polega na tym, że w trybie lokalnym musisz mieć uruchomiony i uruchomiony Docker. Procedura jest następująca:

• robić docker build
• robić docker run
• wysyłanie żądań w ramach protokołu do funkcji
• zburzyć funkcję

Jest kilka powodów, dla których nie lubimy fn testuwzględniać faktu, że dotyczy to Dockera, tj. Programista musi zbudować obraz i uruchomić go w celu wykonania bardzo prostego testu czarnej skrzynki.

Testowanie jednostkowe w FDK

Przetwarzanie żądań / odpowiedzi protokołów jest kluczową cechą każdego FDK, dlatego oficjalnie obsługiwane FDK są dobrze przetestowane iw 100% zgodne z funkcją Fn.

Pomimo pewnych drobnych różnic, rdzeń FDK jest taki sam. Jednak niektóre FDK zapewniają funkcje specyficzne dla języka programowania, takie jak obietnice w FDK-Node i async / await w FDK-Python. Jedną z kluczowych cech oficjalnie obsługiwanego FDK jest to, że rozważa się jego wprowadzenie do testów jednostkowych. W tym konkretnym momencie tylko Java FDK zapewnia niezbędne API do pisania testów jednostkowych (JUnit) w najbardziej efektywny sposób. Mamy nadzieję, że wkrótce udostępnimy te same funkcje z dodatkowymi FDK.

Począwszy od wersji 0..0.33, Python FDK zapewni rozbudowane środowisko do uruchamiania testów jednostkowych. Rzućmy okiem na zestaw testów dla funkcji bezserwerowej Python FDK:

Jak być może zauważyłeś, pomysł polega na dostarczeniu standardowego schematu funkcji wraz z natywnymi testami jednostkowymi, które obejmują daną implementację (testy pozostaną stabilne, dopóki implementacja funkcji pozostanie taka sama). Jeśli spojrzysz na zestawy testów, zobaczysz następujące metody potwierdzania:

assertInHeaders - allows asserting header(s) presence in response
assertInTime - allows asserting the time necessary for a function to finish
assertNotInTime - allows asserting the time within a function was not able to finish
assertResponseConsistent - allows to check the response data, if the data corresponds to assertion expectations

Jak przeprowadzać testy?

Jeśli znasz natywne narzędzia testowe - po prostu użyj PyTest . Jeśli nie, nie martw się, wystarczy zainstalować pytestnarzędzie i uruchomić następujące polecenie:

pytest -v -s --tb=long func.py

Dzięki temu poleceniu otrzymasz następujące dane wyjściowe:

Dzięki dodatkowym wtyczkom pytestmożesz uzyskać pokrycie testu. Użyj następującego polecenia, aby zainstalować wtyczkę pokrycia:

pip install pytest-cov

pytest -v -s --tb=long --cov=func func.py

Poniższe linki mogą być przydatne jako ogólne uzupełnienie tego postu:

• Spójrz na istniejące FDK .
• Zasubskrybuj kanał Fn na YouTube .
• Aby dowiedzieć się więcej o platformie Fn, odwiedź stronę główną projektu .