Quan es llancen noves característiques, la prova segueix sent la barrera més gran. Normalment, el flux de treball va alguna cosa així: construir una característica, crear un PR, empènyer a CI, esquiar a través d'algunes captures de pantalla, i esperem que res es trenqui en la producció quan l'usuari colpeja. Ara, no m'equivoqui, l'enviament ràpid de noves característiques és fantàstic, però les proves manuals simplement no poden seguir endavant.I tot i que les eines per a les proves existeixen, no estan integrades amb la resta del seu flux de treball. Això em porta a un altre punt: planifiquem en una eina, construïm en una altra, revisem en un altre lloc i desplegem en un altre. Afortunadament, hi ha una manera. Linear, Cursor, Vercel i QA.tech formen una pila d'eines que treballen junts, gestionen cada tasca automàticament i et permeten mantenir-te centrat en la construcció. Junts, reemplacen els fluxos de treball de prova manual amb l'automatització de la prova d'IA que s'executa en cada PR. En aquest article, et guiaré a través de la construcció d'una aplicació de flux de pagament de demostració utilitzant aquestes eines. Veuràs com funcionen junts i com t'ajuden a enviar més ràpid sense trencar les coses. Crear un flux de pagament que realment funcioni Per demostrar aquest flux de treball, construirem un flux de pagament en 4 passos: Revisió CART Informació de navegació Detalls de pagament Pàgina de confirmació La resposta és simple: és un procés de negoci bàsic que ve amb múltiples casos d'avantguarda com ara carretons buits, cancel·lació de pagaments, sessions expirades, etc. Si alguna cosa es trenca aquí, perds els teus ingressos. Aquí teniu l’estaca que utilitzarem: Lineal per a un treball clar i rastreable Cursor per a la construcció a la velocitat del llamp Instant Preview per a les instal·lacions QA.tech per a una prova end-to-end (E2E) Tècnica Comencem amb l’eina de planificació. Planifica-ho en lineal, construeix-ho en cursor Planificació lineal Dividiré l'aplicació de flux de pagament en tasques senzilles i rastreables. El focus principal d'aquest article serà l'addició de la funcionalitat de codis de cupons a l'etapa de revisió de la cistella del procés de pagament. Primer, creem un bitllet lineal. Pot ser alguna cosa com "Funció: Construir flux de pagament amb validació de cupons." A causa d'aquesta demostració, introduirem un error en la validació del costat client de la funció de codi de cupó. I per especificar-ho, no serà un error brillant. Serà un error que només apareix sota certes condicions. En altres paraules, el que passa per les revisions humanes i les proves de guió. Construcció ràpida amb cursor El codi complet per a la nostra aplicació demo es troba al GitHub . repositoris Quan obriu Cursor, creeu un nou directori per començar a construir l'aplicació. Suposem que voleu crear un component de cistella en l'aplicació de flux de pagament de 4 passos. Es podria donar a Cursor una invitació com: "Construir un component de cistella per a l'aplicació per a enumerar els articles amb preus i quantitats". Crearà una i I també Arxiu de cartes Un pas de pagament Observeu com Cursor gestiona l'estructura de components, els tipus de prop, la instal·lació i la importació de paquets, i molt més? ara la vostra tasca és centrar-vos en la lògica empresarial, com ara "Quant de descompte s'ha d'aplicar quan S’ha utilitzat el cupó?” SAVE10 Passem a la fase de desplegament utilitzant Vercel. Deploy a Vercel en segons La implantació avui dia és tan fàcil com la construcció amb Cursor. No escrius comandes per enviar el teu codi. És com un clic a la taula de control: selecciona el teu repositori GitHub i dóna-ho a Vercel per a la implantació. Una vegada que el codi estigui fet, només el pressionem a GitHub. Això és tot el que necessita; des d'allà, Vercel gestiona tot per al desplegament automàticament. Però per què Vercel? Simplement perquè li permet visualitzar les implementacions abans que el seu codi es molesti en la producció. Per què Preview Deployments Matter per a CI/CD? Les implementacions de previsió canvien la forma en què treballem.Amb eines com la DX de Vercel, cada PR rep la seva pròpia URL, com , juntament amb un entorn plenament funcional i etern. checkout-app-pr-987.vercel.app Quan el desenvolupador empenta el codi que implementa el nostre nou procés de pagament, així com el bug de cupó ocult, aquí està el que passa automàticament a través de Vercel: L'últim codi es recupera de GitHub; La pròpia aplicació està construïda; L'aplicació es distribueix a una URL de visualització única que es pot compartir (per exemple, checkout-app-pr-987.vercel.app). Aquest desplegament individual assegura la velocitat. Els errors es fixen sense interferir o retardar cap altre projecte. No més "funciona en la meva màquina". L'aplicació de checkout ja està en viu i disponible per a proves. Let QA.tech Handle the Tests Que QA.tech gestioni les proves Aquí ve la part interessant: la prova automatitzada alimentada per IA. En comptes de passar hores provant la seva eina manualment o escrivint i mantenint els scripts de Playwright o Cypress, descriu casos de proves en anglès senzill i l'agent gestiona la resta. Tècnica Afegiu el vostre projecte a QA.tech i apunteu-lo a la vostra URL desplegada per Vercel. QA.tech escanejarà l'aplicació web i coneixerà l'estructura creant un gràfic de coneixement. Crearem algunes proves per a la nostra aplicació.Obrir el xat i descriure el que voleu provar.Per exemple, "Crear 3-4 proves inicials per a la meva aplicació". Recordeu, ja sap tot sobre la vostra aplicació, com ara on es troba la cistella, com omplir els formularis d'enviament, on viu el botó de pagament i la pàgina de confirmació. Podeu crear aquest cas de prova manualment a través del botó “Adicionar cas de prova” o generar-lo en el xat, demanant alguna cosa com, “Testeu el missatge de confirmació de codi de cupó per a pantalles mòbils en el pas 3”. QA.tech generarà automàticament les proves basades en la vostra entrada i les executarà directament contra la vostra aplicació en viu. El bug que Cursor va deixar durant la construcció de l'aplicació va ser capturat per QA.tech, cosa que va causar que el test fracassés. També ens va proporcionar tots els passos rellevants, juntament amb els registres, els detalls de la xarxa i els resultats de les proves. Aquestes són precisament les perspectives que necessitem per depurar el problema de manera eficient. Tècnica En primer lloc, connectar el Anar a Configuració → Integracions → GitHub App. Seleccionar el repositori corresponent aquí, i permetre l'opció "Run on PRs" de la prova de petició de recollida. Aplicació GitHub A continuació, connecteu Linear, de manera que els nostres errors puguin fluir directament a la nostra eina de gestió de projectes. Per fer-ho, aneu a Configuració → Connexions d'organització → Connectar lineal. A continuació, a la secció Configuració del projecte → Integracions → Lineal, seleccioneu el vostre equip des de la descàrrega i guardar-lo. Ara crearem bitllets d'emissió en Linear directament de QA.tech. Tingueu en compte com QA.tech ja ha llistat el nostre cas de prova fallida sota la secció de problemes, donant-vos l'opció d'exportar aquest error directament al vostre compte Linear? Feu clic a "Crear problema en lineal" al tauler de control. El tauler lineal mostrarà ara el problema creat per amb detalls com el tipus, la primera vista, la descripció i un enllaç a la prova. Tècnica Ara ve la part automatitzada. Fixarem aquest bug i veurem com funcionen les eines junts. Fix, Push, Repeat (El flux de treball actual) Tornar a Cursor. Fixarem el problema identificant on es va produir el bug. en El problema és que estem utilitzant en la classe de missatge de confirmació, fent que no es mostri a les pantalles mòbils. PaymentStep.jsx hidden <div className="bg-indigo-50/60 p-4 rounded-2xl border border-indigo-200 border-dashed"> <p className="text-sm font-semibold text-indigo-700">Have a coupon?</p> <div className="sm:flex-row flex flex-col gap-3 mt-3"> <input type="text" value={couponInput} onChange={(event) => onCouponInputChange(event.target.value)} placeholder="SAVE10" className="text-slate-900 focus:border-indigo-500 focus:outline-none focus:ring-2 focus:ring-indigo-100 px-4 py-3 w-full text-base bg-white rounded-xl border border-indigo-200 shadow-inner" /> <button type="button" onClick={onApplyCoupon} className="hover:bg-indigo-500 px-6 py-3 text-base font-semibold text-white bg-indigo-600 rounded-xl transition" > Apply </button> </div> {couponStatus === "applied" && ( <p className="sm:block pt-3 text-sm font-medium text-emerald-600"> SAVE10 applied — enjoying 10% off the subtotal. </p> )} {couponStatus === "invalid" && ( <p className="sm:block hidden pt-3 text-sm font-medium text-rose-600"> That code is not active. Try SAVE10 for this order. </p> )} </div> Un cop fet això, empènyer els canvis més recents i crear un PR amb una nova branca. Ara, l'aplicació GitHub de QA.tech detecta el PR. Analitza els canvis i selecciona les proves rellevants, com les proves de validació de cupons que vam crear anteriorment. Executa aquestes proves contra la URL de previsió de Vercel: sense intervenció manual, sense fer clic a través de l'aplicació. el bot de QA.tech executarà les proves i comentarà en el PR per donar actualitzacions en temps real a l'usuari. En el nostre quadre QA.tech, totes les proves han passat i el missatge de validació apareix ara correctament en el mòbil. El bot QA.tech aprova el PR i els comentaris sobre el seu PR amb el resum complet de la prova. El procés complet (actualització del codi, fusió, desplegament i proves) va trigar aproximadament 5-8 minuts sense intervenció manual. Cada futura sol·licitud de retirada (PR) seguirà el mateix procés: fer canvis, empènyer i deixar que les proves s'executin automàticament. Embolicant-lo fins a Cada eina d'aquest nou constructor d'IA destaca en una cosa. Linear proporciona l'enfocament necessari per a la planificació ràpida i el seguiment de problemes, Cursor accelera el flux de treball de desenvolupament de productes, Vercel ens dóna URL de previsió de desplegament instantani, i QA.tech gestiona les proves automàticament. Malgrat la importància de cada pas en el procés, la prova és sovint l'única cosa en què els equips dediquen menys temps. I la millor part és que no cal mantenir els scripts de proves. Afegiu una característica i QA.tech crearà noves proves. Canviar un flux d'interfície d'usuari i les proves s'actualitzaran automàticament. Preparat per deixar d'escriure, mantenir i desfer-se de les proves E2E fràgils? Obteniu una demostració avui i vegeu com QA.tech transforma el vostre flux de treball de proves. Preparat per deixar d'escriure, mantenir i desfer-se de les proves E2E fràgils? Obteniu una demostració avui i vegeu com QA.tech transforma el vostre flux de treball de proves.
