Try using it in your preferred language.

English

  • English
  • 汉语
  • Español
  • Bahasa Indonesia
  • Português
  • Русский
  • 日本語
  • 한국어
  • Deutsch
  • Français
  • Italiano
  • Türkçe
  • Tiếng Việt
  • ไทย
  • Polski
  • Nederlands
  • हिन्दी
  • Magyar
translation

Dit is een door AI vertaalde post.

Alien Story

Wat voor tests moet je uitvoeren bij het ontwikkelen van een app voor één persoon?

Selecteer taal

  • Nederlands
  • English
  • 汉语
  • Español
  • Bahasa Indonesia
  • Português
  • Русский
  • 日本語
  • 한국어
  • Deutsch
  • Français
  • Italiano
  • Türkçe
  • Tiếng Việt
  • ไทย
  • Polski
  • हिन्दी
  • Magyar

Samengevat door durumis AI

  • Benadrukt het belang van het schrijven van testcode vóór het uitbrengen van de app en presenteert een prioriteit voor verschillende testmethoden, zoals mensen-testen, integratietesten, eenheidstesten en acceptatie- en widget-testen.
  • Ontwikkelaars moeten prioriteit geven aan mensen-testen en integratietesten (provider-gericht) vanwege de tijdsefficiëntie, eenheidstesten na de release toevoegen en acceptatie- en widget-testen vanwege de tijdrovende aard efficiënt uitvoeren.
  • Automatiseer tests om tijd te besparen, de ontwikkelingsnelheid te verhogen en een snelle release als doel te stellen.

"Een grotere broekriem dan de broek is niet goed. Dat wil zeggen, het heeft geen zin als het langer duurt om tests te schrijven."

Ga je al je tijd besteden aan het schrijven van tests?



Het verhaal van het schrijven van tests


Voordat ik de app lanceer, wil ik een eenvoudige testcode uitvoeren. Eigenlijk is het automatiseren van tests, dus ik denk dat het beter is om het nu te doen in plaats van later spijt te krijgen.



De prioriteit voor testen is in mijn ogen:

Menselijke test > Integratietest (alleen provider) > Unittest > Widget, acceptatietest



1. Gewoon testen met mensen

"Gewoon laten doen door mensen is het antwoord"

Ik ga eerst integratietests uitvoeren om de gebruikersstroom in grote lijnen te bekijken. Dan heb ik de tests in ieder geval al een keer uitgevoerd, dus dat is toch goed?



2. Unittest

"Testen of de kleinste onderdelen goed werken"

Eigenlijk is de prioriteit iets lager omdat er geen andere mensen zijn die code mergen (aangezien het om een ​​eenmansontwikkeling gaat). Eerst ga ik een snelle test uitvoeren om te zien of het werkt, dan publiceer ik de app en schrijf ik unittests. Het zal werken omdat ik het heb ontwikkeld. De kans op bugs is op dit moment klein, tenzij er updates of toevoegingen worden gedaan.



3. Integratietest

"Eigenlijk providertesten. Laten we ons daarop concentreren"

Ik denk dat het in mijn app eigenlijk providercontrole is. Ik heb geen tijd om alles opnieuw te maken, en alle stromen worden meestal via riverpod uitgevoerd, dus denk je dat het een stuk minder bugs veroorzaakt als we dit alleen al doen?



4. Acceptaite- en widgettest

"Belangrijk, maar... kost veel tijd"

Het controleren van de gebruikersstroom en het testen van widgets is eigenlijk heel belangrijk. Maar het probleem is... het kost ongelooflijk veel tijd om dit te schrijven. Het is moeilijk om alle takken te controleren, en het is eigenlijk onmogelijk om alles zelf te schrijven... en het is geen garantie dat de tests 100% veiligheid garanderen. Daarom denk ik dat de prijs-kwaliteitverhouding niet zo goed is. Ik denk dat we de integratieprovider testen en als er iets niet werkt, dan kunnen we de gebruiker waarschuwen... en dat deel kunnen we dan op dat moment bijwerken.


Het is misschien wat onverantwoordelijk, maar het lijkt de beste optie te zijn.




Mijn gedachte


Eigenlijk is testen hetzelfde als automatiseren. Het is een goede manier om tijd te besparen door handmatige tests te automatiseren.

Tijd is geld, dus laten we snel de dringende zaken ontwikkelen en de lanceringsdatum versnellen.



De tijd dringt. We moeten zo snel mogelijk ontwikkelen.





Over de ontwikkelaar

De wereldwijde dating-app Alien wordt samen ontwikkeld en beheerd door een echtpaar uit verschillende landen.


Youtube : https://www.youtube.com/@AlienApp
E-mail: slugj2020@gmail.com





Alien
Alien Story
Alien developer & international couple
Alien
Het eerste verhaal van een alien-app-ontwikkelaar Het verhaal van een ontwikkelaar die ervoor kiest om een ​​globale blog te starten met durumis. Hij wil zijn internationale dating-app promoten met behulp van ondersteuning voor 38 talen en automatische YouTube-vertaaltools. Hij runt ook een YouTube-kanaa

21 april 2024

Alien-appserverregiokeuze (AWS) Dit artikel behandelt het ontwerp en de implementatie van een AWS-server voor de Alien Global Dating-app. Naast de noodzaak van ondersteuning voor meerdere regio's en automatische schaling, worden de criteria voor regiokeuze en het plan voor het gebruik

8 mei 2024

Waarom internationale huwelijken geweldig zijn Het verhaal van een ontwikkelaar die een dating-app voor internationale koppels heeft gemaakt. De app belicht de voordelen van het ontmoeten van mensen uit andere landen en de doelen die de ontwikkelaar wil bereiken met de app. Bekijk ook het YouTube-kana

5 mei 2024

Teksttest Er is geen voorvertoning van durumis AI.
안민수
안민수
안민수
안민수

29 april 2024

Prisma Client-mocken voor unit-tests in NestJS Het verwijderen van externe afhankelijkheden is belangrijk bij het testen van eenheidstoepassingen. Met de Jest-mock-methode van Prisma ORM kunt u eenvoudig eenheidstests uitvoeren. Door het installeren van het pakket jest-mock-extended en het mocken van
제이의 블로그
제이의 블로그
제이의 블로그
제이의 블로그

2 april 2024

We maken automatiseringsprogramma's om de productiviteit te verhogen. Durumis ontwikkelt automatiseringsprogramma's om de productiviteit te verhogen. U kunt taken op verschillende gebieden automatiseren, zoals werk, hobby's en het dagelijks leven, en ze gebruiken als uw eigen robotassistent. We bieden automatiseringsservice
(로또 사는 아빠) 살림 하는 엄마
(로또 사는 아빠) 살림 하는 엄마
(로또 사는 아빠) 살림 하는 엄마
(로또 사는 아빠) 살림 하는 엄마
(로또 사는 아빠) 살림 하는 엄마

22 maart 2024

[SI-ontwikkelaarverhaal] 09. De start van de daadwerkelijke ontwikkeling na toewijzing aan het SI-project Een SI-ontwikkelaar ontwikkelt na toewijzing aan een project de functionaliteit van de RFP volgens het WBS-schema. Omdat de eisen van de klant vaak veranderen, treedt codeduplicatie op en ligt de nadruk meer op het implementeren van functionaliteit dan op
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자

18 april 2024

[Niet-technisch, overleven als ontwikkelaar] 7. Wat helpt en wat helpt niet bij het vinden van een nieuwe baan Bij het voorbereiden op een baan als ontwikkelaar is een technische blog niet efficiënt, maar GitHub wordt aanbevolen voor projectbeheer en het delen van broncode. Van verschillende certificeringen is het aan te raden om de informatieverwerkingstechnicus
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자

29 maart 2024

[Niet-technisch, overleven als ontwikkelaar] 3. Waarom ik een ontwikkelaar wil worden Er zijn veel redenen om een ​​ontwikkelaar te willen worden, maar om te slagen, moet je een duidelijk doel hebben en er consequent aan werken. Problemen oplossen en continu leren zijn essentiële aspecten voor ontwikkelaars. Het is belangrijk om te streven
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자
투잡뛰는 개발 노동자

28 maart 2024