spock interview questions with answers
Fjern Spock-intervjuet ditt med denne listen over Spock-intervjuspørsmål vellykket:
I dette Spock Tutorials for All , vi utforsket alt om Integrasjon og funksjonstesting i Spock i vår forrige opplæring.
Denne opplæringen vil dekke de vanligste intervjuspørsmålene rundt Spock-rammeverket.
Vi vil også prøve å forstå Spock fixture-metoder og innebygde utvidelsesstøtte som gjør Spock til et veldig kraftig verktøy for mange testtyper som Unit, Integration og end to end.
Mest populære Spock-intervjuspørsmål
Nedenfor er noen av de mest stilte spørsmålene om Spock-intervju med svar og eksempler.
La oss utforske !!
Q # 1) Kan en Spock-test ha flere når og deretter blokkerer?
Svar: Det anbefales generelt å ha små tester eller scenarier, da det kan være en kodelukt å prøve å gjøre mange ting i en enkelt test. Når det er sagt, er det helt gyldig å ha flere når og deretter blokkerer i en test. Testen vil bare bli ansett for å være vellykket når alle daværende blokker er i godkjent tilstand.
hvordan du spiller en mkv-fil på Windows
La oss se et eksempel for å illustrere dette:
def 'illustrate multiple when and then blocks'() { given: def input1 = 50 def input2 = 100 def result when: result = input1 + input2 then: result == 150 when: result = input2 - input1 then: result == 50 }
I kodeblokken ovenfor kan du se at vi har 2 når og deretter blokker.
Vær oppmerksom på følgende punkter:
- Blokkene utføres i rekkefølgen av utseendet, dvs. sekvensielt.
- Svikt av noen som blokkerer vil føre til at testen mislykkes.
- Påstander i alle daværende blokker bør passere for at den samlede testen skal lykkes.
Spørsmål 2) Hva er alle innretningsmetodene som er tilgjengelige i Spock?
Svar: Fixture-metoder er som tilbakeringinger som kalles når en bestemt hendelseskrok utløses.
Spock leverte 4 testinnretninger som utløses mot forskjellige hendelser:
- setupSpec - Kjører en gang før hele Spec-filutførelsen starter.
- cleanupSpec - Kjører en gang når alle testene i den gitte Spec-filen er utført
- oppsett - Kjører en gang før hver test i spesifikasjonen.
- rydde opp - Kjører en gang etter hver test i spesifikasjonen.
La oss se et kodeeksempel for å illustrere fikseringsmetodene:
class TestFixtureSpec extends Specification { def setupSpec() { println 'in setup spec!' } def cleanupSpec() { println 'in cleanup spec!' } def setup() { println 'in setup!' } def cleanup() { println 'in cleanup!' } def 'test spec1'() { given: println '****test spec1****' } def 'test spec2'() { given: println '****test spec2****' }}
Nedenfor vises utdataene fra ovennevnte kodeeksempel:
i oppsett spesifikasjon!
i oppsett!
**** testspesifikasjon1 ****
i opprydding!
i oppsett!
**** testspesifikasjon2 ****
i opprydding!
i oppryddingsspesifikasjon!
Som vist ovenfor, kan du legge merke til at oppsett- og oppryddingsspesifikasjonen kalles bare én gang for hele spesifikasjonen, og oppsett- og oppryddingstrinn / inventar kalles en gang per test.
Q # 3) Kan Spock-tester brukes til å teste REST-baserte tjenester?
Svar: Ja, Spock-rammeverk kan brukes til å lage E2E- eller integrasjonstester for distribuerte hviletjenester ved bruk av vanlige Java-biblioteker som hvilemal osv. (Vær også oppmerksom på at Spock også kan brukes til å kjøre tester for Spring boot-baserte applikasjoner så vel som med andre rammer som Selen ).
La oss se dette med et enkelt eksempel som bruker Spring's RestTemplate-klasse og utfører en get-operasjon på en offentlig vert API og sjekker at svaret ikke er null.
Eksempel:
class RestApiIntegrationSpec extends Specification { def 'check rest api status'() { when: 'a rest call is performed to the status page' RestTemplate restTemplate = new RestTemplate() String response = restTemplate.getForObject('https://httpbin.org/get', String.class) then: response != null } }
I eksemplet ovenfor kan du referere til Spock-spesifikasjonen som brukes til å hevde svaret fra et offentlig API.
hvordan du fjerner noe fra en array-java
Sp # 4) Hva er begrensningene for Spock-rammeverket?
Svar: Selv om læringskurven for Spock-rammeverket ikke er så bratt som det er lett å lære, gjør den deklarative syntaksen den svært lesbar.
I mellomtiden er det noen få punkter som kan vurderes:
- For applikasjoner på Java-kodebase vil bruk av Spock resultere i å legge til en ny språkstabel, dvs. Groovy.
- Spock-tester går litt tregere enn innfødte JUnit-tester.
- IDE-støtte for Spock er ikke like god som for andre rammer som JUnit.
Til tross for alle de ovennevnte punktene, oppveier fordelene med Spock-rammeverket fortsatt den lille listen over ulemper som Spock har.
Q # 5) Forklar noen av de innebygde utvidelsene til Spock-rammeverket.
Svar: Spock gir mange innebygde utvidelser / kroker / utløsere som for det meste er kommentarbaserte (vi så noen av dem i seksjonen / spørsmålet om testinnretningene).
La oss se noen av den innebygde diskusjonen med eksempler:
@Overse: For å forhindre at en funksjon (eller individuell metode) blir utført. For å bruke bare dekorasjonsmetoden (individuell testmetode) eller en hel spesifikasjon, vil dette sikre at den merkede metoden eller klassen ikke blir utført.
@Ignore def 'check case-insensitive equality of 2 strings'() { given: 'two input strings' String str1 = 'hello' String str2 = 'HELLO world' when: 'strings are lowercased' str1 = str1.toLowerCase() str2 = str2.toLowerCase() then: 'equal strings should return success' str1 == str2 }
@IgnoreRest: Denne merknaden er nyttig når du bare vil velge en og utføre resten av metodene i den gitte spesifikasjonen.
@IgnoreRest def 'check case-insensitive equality of 2 strings'() { given: 'two input strings' String str1 = 'hello' String str2 = 'HELLO world' when: 'strings are lowercased' str1 = str1.toLowerCase() str2 = str2.toLowerCase() then: 'equal strings should return success' str1 == str2 } def 'check addition of 2 numbers'() { given: int input1 = 10 int input2 = 25 expect: input1.getClass().toString() == 'class java.lang.Integer' input2.getClass().toString() == 'class java.lang.Integer' input1 = Integer.MIN_VALUE when: int result = input1 + input2 then: result == 35 }
Som vist i eksemplet ovenfor vil metoden kommentert med @IgnoreRest bli utført, og resten av testene vil bli ignorert.
@IgnoreIf: Denne kommentaren er en betinget ignorering.
For eksempel: Hvis du ikke vil kjøre noen tester på Mac OS, kan du bruke en kombinasjon av @IgnoreIf med System.getProperty (“os.name”) som vil sikre at testene bare kjøres hvis det samsvarende operativsystemet blir funnet .
La oss prøve å forstå dette med nedenstående kodeeksempel:
@IgnoreIf({ System.getProperty('os.name').contains('Mac') }) def 'check case-insensitive equality of 2 strings'() { given: 'two input strings' String str1 = 'hello world' String str2 = 'HELLO world' when: 'strings are lowercased' str1 = str1.toLowerCase() str2 = str2.toLowerCase() then: 'equal strings should return success' str1 == str2 }
I ovennevnte kodeeksempel har vi brukt @IgnoreIf-kommentar med en betingelse på System.getProperty som vil se etter 'Mac' i eiendomsverdien og bare ignorere hvis tilstandsmatchet er vellykket.
La oss se en ekstra utvidelse her, dvs. @Pause: Dette hjelper til med å nevne en tidsavbruddsverdi i enheten du velger for testen under utførelse, og hvis tidsgrensen for tidsavbrudd brytes, vil testen gi et unntak.
Et annet viktig poeng å merke seg her er at @Timeout-merknaden også kan nevnes over hele spesifikasjonen, og dette vil kombinere varigheten på alle de enkelte testene og kaste et unntak i tilfelle terskelbrudd.
@Timeout(value=10, unit= TimeUnit.MILLISECONDS) class SampleSpec extends Specification { def 'check case-insensitive equality of 2 strings'() { //test1 } def 'check addition of 2 numbers'() { //test2 } }
I den ovennevnte koden, hvis den totale kjøringstiden for spesifikasjon overstiger 10 ms, vil scenarioutførelsen mislykkes. Du kan se utdataene med feildetaljer i feilkonsollen.
I likhet med de ovennevnte utvidelsene, er det et par andre innebygde utvidelser, som:
@Krever: Noe som krever at en bestemt tilstand er sant.
@Utgave: For å koble sammen eventuelle feil knyttet til testsaken, etc.
spørsmål om spørsmål og svar på Cisco nettverk
Disse utvidelsene gir Spock-spesifikasjonene mye fleksibilitet og kraft og gir mye kontroll for testutførelsen.
Konklusjon
Dermed har vi dekket de mest populære Spock Intervju-spørsmålene her i denne opplæringen. Læringskurven for Spock er lav på grunn av at språket groovy følger en deklarativ programmeringsstil og er svært lesbar.
Selv om Spock er relativt ny, får Spock popularitet som et valgramme for å skrive forskjellige typer tester i Java eller Groovy-baserte applikasjoner.
Håper, du likte alle de informative opplæringene i denne Spock-serien. Vi er virkelig sikre på at disse opplæringene ville beriket din kunnskap og forståelse av Spock.
PREV Opplæring | FØRSTE veiledning
Anbefalt lesing
- Skriveenhetstester med Spock Framework
- Spock for integrasjon og funksjonstesting med selen
- Spock Mocking and Stubbing (Eksempler med videoveiledninger)
- Datadrevet eller parametrisert testing med Spock Framework
- Spock Tutorial: Testing With Spock And Groovy
- Intervju spørsmål og svar
- ETL Testing Intervju Spørsmål og svar
- 20 mest populære TestNG intervju spørsmål og svar