Kategorien
Angular

End-To-End-Tests mit Angular und Cypress

Um End-To-End-Tests mit Cypress und Angular zu schreiben, können Sie folgende Schritte ausführen:

  1. Stellen Sie sicher, dass Sie die neueste Version von Cypress und Angular installiert haben. Sie können Cypress mit dem Befehl npm install -D cypress installieren.
  2. Öffnen Sie Cypress mit dem Befehl npx cypress open im Hauptverzeichnis Ihres Projekts. Cypress öffnet eine Benutzeroberfläche, in der Sie Ihre Tests aufzeichnen und ausführen können.
  3. Erstellen Sie eine neue Testdatei, indem Sie auf „Add test file“ in der Cypress-Benutzeroberfläche klicken. Sie können die Testdatei auch manuell im Verzeichnis „cypress/integration“ erstellen.
  4. Fügen Sie den folgenden Code in Ihre Testdatei ein, um sicherzustellen, dass Cypress Ihre Angular-Anwendung erfolgreich geladen hat:
describe('My First Test', () => {
  it('Does not do much!', () => {
    cy.visit('http://localhost:4200');
    cy.contains('app-root h1', 'Welcome to my-app!');
  });
});
  1. Führen Sie den Test aus, indem Sie auf die Testdatei in der Cypress-Benutzeroberfläche klicken. Wenn alles erfolgreich war, sollte der Test grün markiert werden.
  2. Erstellen Sie weitere Tests, indem Sie Schritte und Assertions hinzufügen. Sie können Elemente auf der Seite auswählen und auf sie interagieren, indem Sie die Methoden von Cypress verwenden, z.B. cy.get(), cy.click() und cy.type().

Um Cypress mit einem Docker-Container zu verwenden, können Sie folgende Schritte ausführen:

  1. Erstellen Sie eine Dockerfile in Ihrem Projektverzeichnis mit den folgenden Inhalten:
FROM cypress/browsers:node18.6.0-chrome105-ff104

# Install your application's dependencies
COPY package.json yarn.lock ./
RUN yarn

# Add your application code
COPY . ./

# Run the tests
CMD ["yarn", "cy:run"]
  1. Erstellen Sie ein Docker-Image mit dem Befehl docker build -t my-app .
  2. Führen Sie einen Container auf Basis des Images mit dem Befehl docker run -it --rm -v $(pwd):/app my-app aus. Dies führt die Cypress-Tests innerhalb des Containers aus.

Durch das Hinzufügen von -v $(pwd):/app werden Ihre Projektdateien in den Container gemountet und Cypress kann auf sie zugreifen.

Kategorien
Buch Empfehlungen

Buch Review: Clean Code von Robert C. Martin

Clean Code: A Handbook of Agile Software Craftsmanship ist ein Buch von Robert C. Martin, auch bekannt als „Uncle Bob“. Das Buch, das ursprünglich 2008 veröffentlicht wurde, ist ein Leitfaden für die agile Softwareentwicklung und richtet sich an Softwareentwickler, die sauberen, lesbaren und wartbaren Code schreiben wollen.

Im Buch werden Konzepte und Best Practices beschrieben, die dazu beitragen, dass Code einfacher zu verstehen und zu pflegen ist. Dazu gehören unter anderem die Verwendung eindeutiger Namen für Variablen und Funktionen, das Vermeiden von redundanter oder wiederholter Code sowie die Aufteilung von Code in kleine, wiederverwendbare Funktionen.

Die folgenden Regeln sind neben vielen anderen enthalten und werden sehr gut erläutert:

  1. Verwende eindeutige und beschreibende Namen für Variablen, Funktionen und Klassen.
  2. Vermeide redundante oder wiederholter Code, indem du ihn in Funktionen oder Methoden auslagern.
  3. Trenne Verantwortlichkeiten und logische Abschnitte deines Codes in verschiedene Klassen oder Module auf.
  4. Verwende Kommentare, um den Zweck und die Absicht deines Codes zu erläutern.
  5. Schreibe Tests für deinen Code, um seine Korrektheit und Zuverlässigkeit zu überprüfen.
  6. Vermeide Überladung von Funktionen und Methoden, um Verwirrung beim Aufruf zu vermeiden.
  7. Verwende Konstanten anstelle von Hardcoded Werten, um Code lesbarer und wartbarer zu machen.
  8. Vermeide „Magische Zahlen“ und „Magische Strings“ in deinem Code und verwende stattdessen Konstanten oder Enumerations.
  9. Vermeide unveränderliche Zustände und globale Variablen, da sie schwer zu testen und zu verstehen sind.
  10. Schreibe sauberen Code, indem du kleine Schritte und regelmäßiges Refactoring nutzt, um ihn lesbar und wartbar zu halten.

Ein wichtiger Aspekt von Clean Code ist die Testbarkeit. Das Buch betont, dass Code nur dann als sauber angesehen werden kann, wenn er leicht testbar ist und durch Tests nachgewiesen werden kann, dass er korrekt funktioniert. Dies hilft nicht nur, Fehler frühzeitig zu entdecken, sondern auch dabei, sicherzustellen, dass Änderungen am Code nicht unbeabsichtigte Auswirkungen haben.

Insgesamt bietet Clean Code eine umfassende Anleitung für die agile Softwareentwicklung und ist ein wertvoller Ratgeber für alle, die sauberen, wartbaren Code schreiben wollen.

Kategorien
PHP Symfony

PHP Anwendungen automatisiert modernisieren mit rector

Das Tool rector ist eine Konsolenanwendung für automatisiertes Refactoring von PHP Anwendungen.

Damit lassen sich schnell einfache Altlasten entfernen aus Legacy Projekten.

Mit dem folgenden Rector Script (./rector.php) können die gängigsten Refactorings durchgeführt werden:

<?php

declare(strict_types=1);

use Rector\Config\RectorConfig;
use Rector\Set\ValueObject\SetList;

return static function (RectorConfig $rectorConfig): void {
    $setLists = [
        SetList::PHP_52,
        SetList::PHP_53,
        SetList::PHP_54,
        SetList::PHP_55,
        SetList::PHP_56,
        SetList::PHP_70,
        SetList::PHP_71,
        SetList::PHP_72,
        SetList::PHP_73,
        SetList::PHP_74,
        SetList::PHP_80,
        SetList::PHP_81,
        SetList::ACTION_INJECTION_TO_CONSTRUCTOR_INJECTION,
        SetList::CODE_QUALITY,
        SetList::CODING_STYLE,
        SetList::DEAD_CODE,
        SetList::EARLY_RETURN,
        SetList::GMAGICK_TO_IMAGICK,
        SetList::MONOLOG_20,
        SetList::MYSQL_TO_MYSQLI,
        SetList::NAMING,
        SetList::PRIVATIZATION,
        SetList::TYPE_DECLARATION,
        SetList::TYPE_DECLARATION_STRICT,
    ];

    foreach($setLists as $setList) {

        $rectorConfig->import(
            $setList
        );
    }

    $rectorConfig->paths([
        __DIR__.'/src',
        __DIR__.'/tests',
    ]);
};

ausführbar im Dry mode ohne Änderungen am Code mit:

vendor/bin/rector process --debug --dry-run

Kategorien
Docker Symfony

SSO Saml Login mit Symfony

Single-Sign-On ist das Thema der Stunde, es verbessert die Sicherheit und auch die User Verwaltung. Um Saml SSO in Symfony einzubauen gibt es das OneloginSaml Bundle, ein Symfony Wrapper für das php-saml Packet.

Der Vorteil für die Benutzer von SSO liegt darin, dass diese sich morgens einmal authentifizieren müssen und danach den ganzen Tag alle Anwendungen verwenden können ohne sich nochmals einloggen zu müssen.

Der Vorteil für das Unternehmen liegt darin, dass es vorgeben kann, dass die Authentifierung nur mit 2 Faktor Authentifizierung stattfinden kann (z.B. Handy App und Passwort), um mehr Sicherheit zu gewährleisten. Dies kannn in der Zukunft den steigendenden Sicherheitsbedürfnissen angepasst werden. Außerdem können zentral Rechte vergeben werden für User und nach dem Austritt aus dem Unternehmen einfach wieder entzogen werden.

Wenn das Bundle installiert und korrekt konfiguriert ist, benötigt man eine Dev-Umgebung mit einem Identity Provider (IdP). Dafür bietet sich docker-simplesamlphp an:

docker-compose.yml:

version: '3.7'
services:
	idp:
		image: kenchan0130/simplesamlphp
		container_name: idp
		ports:
			- "8080:8080"
		environment:
			SIMPLESAMLPHP_SP_ENTITY_ID: http://localhost/saml/metadata
			SIMPLESAMLPHP_SP_ASSERTION_CONSUMER_SERVICE: http://localhost/saml/acs
			SIMPLESAMLPHP_SP_SINGLE_LOGOUT_SERVICE: http://localhost/saml/logout

Das OneloginSaml Bundle muss folgender Maßen konfiguriert werden:

hslavich_onelogin_saml:
  # Basic settings
  idp:
    # Identifier of the SP entity  (must be a URI)
    entityId: 'http://localhost:8080/simplesaml/saml2/idp/metadata.php'
    singleSignOnService:
      url: 'http://localhost:8080/simplesaml/saml2/idp/SSOService.php'
      binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'
    singleLogoutService:
      url: 'http://localhost:8080/simplesaml/saml2/idp/SingleLogoutService.php'
      binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'
    x509cert: 'insert certificate here'
  # Service Provider Data that we are deploying.
  sp:
    entityId: 'http://localhost/saml/metadata'
    assertionConsumerService:
      url: 'http://localhost/saml/acs'
      binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST'
    singleLogoutService:
      url: 'http://localhost/saml/logout'
      binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'
    privateKey: ''

Die Informationen kann man hier ablesen, auch die vom Zertifikat:

SAML Metadata: http://localhost:8080/simplesaml/saml2/idp/metadata.php?output=xhtml

Wenn man alles richtig konfiguriert hat, dann landet man beim Aufruf der Symfony Anwendung auf der Login Seite des IdP Providers und kann sich dort einloggen:

Login Seite des IdP Providers

Die Logins lauten:

admin:     secret
user1:     password
user2:     password

Dann sollte man sich mit seiner Symfony Applikation lokal über SAML einloggen und testen können.

Kategorien
GIT

mehrere SSH Keys für denselben Hot verwenden

Unter Windows oder Linux können für z.B. github.com oder gitlab.com mehrere SSH Keys verwendet werden, um sich mit unterschiedlichen Accounts auf derselben Domain verbinden zu können.

In der ssh config Datei unter ~/.ssh/config können beide SSH Keys angeben werden mit unterschiedlichen Host Einträgen.

Die Host Einträge kann mann selber vergeben und sie müssen unterschiedlichen sein:

#gitlab 1
Host private_gitlab_com
  Hostname gitlab.com
  PreferredAuthentications publickey
  IdentityFile ~/.ssh/gitlab_private
  
# gitlab 2
Host company_gitlab_com
  Hostname gitlab.com
  PreferredAuthentications publickey
  IdentityFile ~/.ssh/gitlab_company

Das wichtigste ist, das man jetzt beim clone Befehl „gitlab.com“ ersetzt durch den definierten Host Wert.

Aus

git clone git@gitlab.com:foo/bar.git

wird zu:

git clone git@company_gitlab_com:foo/bar.git

Kategorien
Angular

Angular Unit Testing von Komponenten mit Abhängigkeiten

Um einen Unit Test von einer Angular Komponente mit Abhängigkeiten (Dependencies) schreiben zu können, muss man die Abhängigkeiten unter Kontrolle bringen.

Wenn man dies nicht tut, schreibt man einen Integration-Test. Integration-Tests haben eine höhere Komplexität hat und gehen schneller kaputt.

Beipsiel einer Komponente „MyComponent“ mit einer Abhängikeit „MyService“:

export class MyComponent implements OnInit {

  public serviceValue;

  constructor(
    private myService: MyService,
  ) {}

  ngOnInit() {
    this.serviceValue =  this.myService.getValue();
  }
}

Um in einem Jasmine Unit Test die Abhängigkeit von MyService zu kontrollieren, kann man einen Spy einsetzen, der an die die Stelle der Methode MyService::getValue gesetzt wird und die Sachen macht, die man für den Test gern hätte.

describe('MyComponent', () => {
  let component: MyComponent;
  let fixture: ComponentFixture<MyComponent>;
  let myService:MyService;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      declarations: [MyComponent,],
    }).compileComponents();
  });

  beforeEach(() => {
    fixture = TestBed.createComponent(MyComponent);
    component = fixture.componentInstance;
    myService = TestBed.inject(MyService);
  });

  it('spy should set value', () => {
     spyOn(myService,'getValue').and.returnValue('foo');
    fixture.detectChanges();
    expect(component.serviceValue).toBe('foo');
  });
});

In dem Beispiel wird die Methode getValue der Klasse MyService mit einem Spy überschrieben und dem Spy mitgeteilt, dass er den Wert ‚foo‘ zurückgeben soll.

Kategorien
MQTT

MQTT lesen aller Topics

Um alle Topics eines MQTT Brokers zu abonnieren und zu lesen reicht der Befehl aus (bei localhost, Port 1883):

mosquitto_sub -v -t '#'

oder bei nicht localhost und nicht standard Port:

mosquitto_sub -v -h BROKER_IP -p BROKER_PORT -t '#'

Kategorien
Amazon AWS

AWS API Gateway für DynamoDB erstellen

Die Aufgabe ist es eine REST API zu erstellen mit AWS API Gateway, welche Daten lesen und später auch schreiben kann von einer Dynamo DB ohne eine Lambda Funktion zu verwenden.

Wir werden das API Gateway so konfigurieren, dass es die Request Daten validiert und so verändert, dass der DynamoDB Service die Daten verarbeitet.

Dazu erstellen wir in AWS ein nicht private REST API:

REST API Gateway erstellen
DynamoDB NoSql Datenbank erstellen

Berechtigungen vergeben, dass das API Gateway auf die DynamoDB Tabelle zugreifen kann in AWS IAM. Dafür erstellen wir eine Richtlinie in IAM. Die Berechtigung sieht wie folgt aus:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "dynamodb:Scan"
      ],
      "Effect": "Allow",
      "Resource": "ENTER_ARN_OF_YOUR_DYNAMO_DB_HERE"
    }
  ]
}

Die Richtlinie kann mit dem Tool genriert werden: https://awspolicygen.s3.amazonaws.com/policygen.html

Dann muss eine Rolle mit der Richtlinie für den Service API Gateway erstellt werden in IAM. Hinweis: Die Richtlinie kann erst nach dem erstellen der Rolle hinzugefügt werden.

IAM Rolle für das API Gateway mit der erstellten Richtlinie

Dann Erstellen wir in AWS API Gateway eine Resource mit der Richtlinie:

Jetzt wandeln wir den einfacher GET Request /data/all mit leerem Payload um zu einem DynamoDB POST Request, der alle Daten zurückliefert, beschrieben in: https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Scan.html

Die Integrationsanforderung der Resource muss folger Maßen konfiguriert sein:

Weiterleiten des Requests an Dynamo DB als POST Scan Request

Der Request kann über den Testen Button in AWS ausprobiert werden:

Erfolgreicher Test des Endpunktes
Kategorien
Amazon AWS

AWS Policy Generator

Zum generieren von Berechtigungen gibt eine einfaches Web-Tool von AWS, welches einem die Berechtigungen im JSON Format generiert.

Type of policy ist meist IAM policy.

https://awspolicygen.s3.amazonaws.com/policygen.html

Kategorien
Amazon AWS

APIs erstellen mit AWS API Gateway

Amazon API Gateway ist eine Service mit dem man professionelle APIs erstellen kann, welche

  • skalieren
  • sich um die Authentifizierung kümmern
  • serverless sein können zu AWS Labmda oder einem AWS Datern Speicher
  • aber auch über HTTP(S) zu einer EC2 Instanz weiterleiten können
mögliche verbindbare serverless Services
serverless Datenbank Funktionalität
serverless Website Hosting

Das AWS API Gateway kann den Request validieren, verändern und auch beantworten/abbrechen um Traffic zu sparen.

Zur Authentifizierung können verschiedene Methoden verwendet werden über JWT Token, Basic Auth, Custom HTTP URLs und eigene Lambda Funktion.

https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html

AWS Cognito zur Authentifizierung und User Management

Man kann aus der Schnittstelle ein SDK generieren, welches die Client zur Integration verwenden können und die Authentifizierung erleichtern. Derzeit werden unterstützt:

  • Java
  • Android
  • iOS
  • JavaScript
  • Ruby

https://docs.aws.amazon.com/de_de/apigateway/latest/developerguide/how-to-generate-sdk-console.html

Erstellen eines SDK für Clients zum einbinden der Schnittstelle

Alles Requests/Responses können gelogt werden und analysiert werden in AWS CloudWatch.

Die CORS Regeln können damit verwaltet werden.

Die API lässt sich mit Hilfe von Open API/Swagger 3.0 definieren.

Es können neben REST/HTTP auch Websocket APIs erstellt werden.

Canary Release Möglichkeit: Es werden nur 10% der Requests auf den neu releasten Endpunkt, um zu schauen, ob soweit alles funktioniert:

https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html

Preis-Übersicht:

https://aws.amazon.com/de/api-gateway/pricing/

Empfohlene Videos: