diff --git a/_posts/2020-03-30-angular-cypress-typescript-e2e-testing/2020-03-30-angular-cypress-typescript-e2e-testing.md b/_posts/2020-03-30-angular-cypress-typescript-e2e-testing/2020-03-30-angular-cypress-typescript-e2e-testing.md
index 2f6367d3..da661b81 100644
--- a/_posts/2020-03-30-angular-cypress-typescript-e2e-testing/2020-03-30-angular-cypress-typescript-e2e-testing.md
+++ b/_posts/2020-03-30-angular-cypress-typescript-e2e-testing/2020-03-30-angular-cypress-typescript-e2e-testing.md
@@ -27,7 +27,7 @@ categories: "cypress testing typescript"
 - [Fazit](#fazit)
     - [Quellen und Hinweise](#quellen-und-hinweise)
 
-Früher habe ich in der Frontend Entwicklung mit [.NET und WPF von Microsoft](https://docs.microsoft.com/en-US/dotnet/framework/wpf/) gearbeitet und erinnere mich noch gut an die Zeiten, in denen wir kostenintensive Frameworks zum Schreiben von End-to-End Tests für unsere Projekte evaluiert haben. Nach vielen Wochen, sogar Monaten der Evaluation, der Entwicklung von speziellem *Glue-Code* oder einer eigenen Test-Infrastruktur auf Basis existierender Werkzeuge, hatten wir es endlich geschafft, unsere E2E Tests zum Laufen zu bekommen. Leider waren sie ziemlich brüchig und sind oft fehlgeschlagen. Wir mussten händische Anpassungen machen oder hatten Probleme mit unzuverlässigen Test-Runnern in unserer Continuous Integration Pipeline.
+Früher habe ich in der Frontend Entwicklung mit [.NET und WPF von Microsoft](https://learn.microsoft.com/en-us/dotnet/desktop/wpf/?view=netdesktop-9.0) gearbeitet und erinnere mich noch gut an die Zeiten, in denen wir kostenintensive Frameworks zum Schreiben von End-to-End Tests für unsere Projekte evaluiert haben. Nach vielen Wochen, sogar Monaten der Evaluation, der Entwicklung von speziellem *Glue-Code* oder einer eigenen Test-Infrastruktur auf Basis existierender Werkzeuge, hatten wir es endlich geschafft, unsere E2E Tests zum Laufen zu bekommen. Leider waren sie ziemlich brüchig und sind oft fehlgeschlagen. Wir mussten händische Anpassungen machen oder hatten Probleme mit unzuverlässigen Test-Runnern in unserer Continuous Integration Pipeline.
 
 Ein paar Jahre später mit [Angular](https://angular.dev/) und [Protractor](https://www.protractortest.org/#/) als voreingestelltem E2E Testing-Framework sind die Tests weiterhin basierend auf sogenannten [Page Objects](https://www.protractortest.org/#/page-objects) und dem [Selenium Web Driver](https://www.selenium.dev/). Unzuverlässig sind sie immer noch. Keine teuren, kommerziellen Frameworks oder maßgeschneiderte Infrastruktur war mehr notwendig. Aber hat es Spaß gemacht E2E Tests zu schreiben? Nein.