Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Improve tests of constructs

Aperta
  • Qualcosa non va?
#99 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
aws, python
Ambito
cloud, infrastructure, testing

Direzione di ricerca

Inizia esaminando i test di deployment esistenti e il relativo scenario attuale di deploy-destroy. Confronta questo approccio con la documentazione di AWS CDK su integ-tests-alpha e con l'entry point integ-runner collegato, quindi determina se supportano il test della raggiungibilità delle applicazioni distribuite e di configurazioni aggiuntive dei construct. Il lavoro sarà completo quando sarà stato definito l'ambito dei test e saranno stati documentati i casi o le modifiche al framework.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Now that we finally having deployment tests that work, here are ideas to improve them.

  • For now we're essentially just testing that we're writing proper CDK code that produces cloud formation templates that we can use to deploy-destroy without bugs. We're not testing any of the deployed applications (initially I had planned to include that, i.e ingest some test metadata and test usage of the STAC api, the raster API, etc, but other challenges piled up and I wanted to get something out of the door so I simplified the tests to just a deploy-destroy process). Should we add actual tests of the apps at some point ? Ideally it shouldn't contain too much application logic (these tests should live in the actual app repositories, titiler-pgstac, etc). Maybe simple checks that the APIs are reachable ?

  • We only have one test case that's quite specific : no STAC ingestor, STAC browser or bastion host, the DB is in a public subnet and allows connections from any IP (only barrier is the password), application lambdas are not placed in VPCs. Should we add different configuration cases in the test deployments ?

  • Now that I am writing about this, I am thinking there must be some framework we can reuse for doing real world testing of our constructs, since there are a lot of constructs being developed out there. Just stumbled upon this, not sure if it does what we want. I think it's meant to be use with this CLI tool https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/integ-runner developed by AWS for their own constructs repository, which essentially does what we're doing (try to synth, deploy and destroy templates resulting from constructs) but in a more fancy way.

Lingua principale
Python
Stelle
29
Fork
6
Merge medio
10h 50m
PR unite (30g)
5

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di developmentseed/eoapi-cdk

Tutte le issue di developmentseed/eoapi-cdk

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.