2 Vigtige Selen-designmønstre og bedste praksis

I denne tutorial lærer vi om Selen-designmønstre og bedste praksis, mens vi arbejder med Selenium Automation-rammeudvikling (hybrid ramme i selen), der er to variationer af Framework Design eller Framework-model, som vi skal overveje, som er: 

Vi skal vide og forstå, hvorfor sprogdesignmønster er påkrævet, når vi udvikler vores ramme i en af ​​Selen rammemodel. Vi vil foreslå at gennemgå de tidligere segmenter af Selenium Framework udvikling tutorial serie for at få hele forståelsen.

Lad os forstå det detaljeret: 

selen design mønstre og bedste praksis -hybrid ramme i selen

Mens vi designer en hvilken som helst ramme, skal vi overveje en vis designarkitektur, dvs. selendesignmønstre og bedste praksis, og alt efter behovet for typen af ​​rammemodellen skal vi vælge et sprog Design mønster at løse problemtilstanden for rammedesignet som helhed.

Derfor bare for at konkludere, kan vi vælge en Selen-rammemodel (Hybrid, Sideobjektmodel, Datadrevet osv.), men for at implementere modellen skal vi følge og implementere nogle sprogdesignmønstre (f.eks. java/C#-designmønstre) 

Hvorfor har vi brug for selen designmønster og bedste praksis, når vi bygger Selenium Framework: 

Hvilke designmønstre, der skal bruges i Selenium Framework: 

Der er et par designmønstre, du kan bruge til at implementere forskellige områder af rammen, såsom et eksempel: 

Vi vil lave den live kodningsskabelon for hele Framework i de kommende stillinger her.

Singleton designmønster til hybrid ramme i selen: 

Singleton Design Pattern er et mønster, hvor du kun kunne oprette et objekt fra en klasse og komme til at bruge det samme objekt til at få adgang til klassens metoder; Vi kunne bruge designmønsteret i konfiguratoren, hvor vi kun behøver at læse konfigurationsdataene og kan indlæses i et datalager (enhver form for datastruktur, som du kan bruge, når og når det er nødvendigt, mens du er i udførelsen fra alle klasser og metoder) 

Så vi kunne opnå det samme på nedenstående måde, mens vi designede det samme med Singleton Design-mønster. 

BEMÆRK: Vi designer og udvikler rammen fra bunden i det kommende afsnit af tutorial-serien, men denne specifikke tutorial giver dig indsigt i nødvendigheden af ​​designmønsteret.

pakke com.cyborg.core.generic.dataUtils; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.IOException; importer java.io.InputStream; importer java.util.LinkedHashMap; import java.util.Properties; import java.util.Set; import org.apache.log4j.PropertyConfigurator; // Dette er SingleTon Class public class PropertiesDataUtils { private Properties properties = null; offentlig statisk LinkedHashMap configDataStore = nyt LinkedHashMap (); InputStream er = null; // Dette er den statiske og private reference for klassen, som du kan bruge hvor som helst i dit framework private static PropertiesDataUtils propertiesDataUtils = null; boolesk centralizeLog = falsk; // Dette er den private konstruktør til at skabe objektet, men du kan ikke få adgang til dette uden for klassen for at vedligeholde designet af SingleTon-mønsteret, dvs. kun oprettelse af ét objekt.
 private PropertiesDataUtils(String filePath) { generateDataStore(filePath); centralizeLog = Boolean.parseBoolean(PropertiesDataUtils.configDataStore.get("centralizedLog")); if(centralizeLog) PropertyConfigurator.configure(System.getProperty("user.dir")+"//src//test//resources//config//log4j_central.properties"); else PropertyConfigurator.configure(System.getProperty("user.dir")+"//src//test//resources//config//log4j_local.properties"); } private PropertiesDataUtils() { } // Denne metode skaber grundlæggende instansen af ​​SingleTon-klassen public static PropertiesDataUtils getInstance(String filePath) { if (propertiesDataUtils == null) propertiesDataUtils = new PropertiesDataUtils(filePath); returnere egenskaberDataUtils; } // denne metode opretter dybest set datalageret, hvor du vil gemme alle konfigurationsdataene som tidligere diskuteret private void generateDataStore(String filePath) { try { this.properties = new Properties(); is=ny FileInputStream(filsti); egenskaber.belastning(er); overrideFromEnvironment(); Sæt keys = loadAllKeys(); for (Objekt k : nøgler) { String key = (String) k; configDataStore.put(nøgle, getPropertyValue(nøgle)); } } catch (FileNotFoundException fileNotFoundException) { String exceptionData = String.valueOf(fileNotFoundException.getCause().getMessage()); } catch (IOException ioException) { String exceptionData = String.valueOf(ioException.getCause().getMessage()); } endelig { if (null != er) { prøv { is.close(); } catch (undtagelse e) { String exceptionData = String.valueOf(e.getCause().getMessage()); } } } } // Denne metode bruges til at indlæse alle nøglerne fra egenskabsfilen.

Ved denne tilgang kunne vi bruge Singleton-designmønsteret og bruge det i vores rammer.

Fabriksdesignmønster i selenramme: 

I fabriksdesignmønsteret opretter vi en klasse (vi kalder det en fabriksklasse), og på den anden side har vi en klasse interface og til sidst implementeret af "n" antal klasser.

Fabriksklassen returnerer dybest set objektet til de ovennævnte klasser (afhængigt af behovet), så du ikke behøver at håndtere ovenstående “N” antal klassers objekt; snarere kan du oprette et objekt af fabriksklassen og kalde metoden for fabriksklasse, som returnerer det nødvendige basislinjeobjekt for de krævede klasser blandt adobe “n” -klasser.

Nu kan du overveje dette design, mens du opretter den forskellige implementering af Webdriver / browser. 

Vi har forskellige browser og implementeringen med en anden type selen driver (f.eks. LocalDriver, RemoteDriver, ThreadDriver osv.), og når du har brug for en bestemt type driver og en bestemt type browser, kan du nævne i konfigurationsfilen, og baseret på behovet vil fabriksklassen give dig forekomsten af driveren og browseren til dit automatiseringsscript til at bruge yderligere. 

Her er kodebasen til implementering af dette designmønster, mens du opretter driver-browser-interaktioner: 

Interface design: 

pakke com.cyborg.core.web.utils.driverUtils; import org.openqa.selenium.WebDriver; import org.openqa.selenium.remote.RemoteWebDriver; public interface IDriver { public WebDriver init(String browserName); }

"N" antal gennemgang af gennemgangsklasser (som implementerer grænsefladen):

pakke com.cyborg.core.web.utils.driverUtils; import org.openqa.selenium.WebDriver; import org.openqa.selenium.chrome.ChromeDriver; import org.openqa.selenium.edge.EdgeDriver; import org.openqa.selenium.firefox.FirefoxDriver; import org.openqa.selenium.ie.InternetExplorerDriver; import org.openqa.selenium.safari.SafariDriver; public class LocalDriver implementerer IDriver { public WebDriver init(String browserName) { String pathToDriver = getDriverPath(browserName); if (null != browserName) { switch (browserName) { case "chrome": System.setProperty("webdriver.chrome.driver", pathToDriver); returner ny ChromeDriver(); case "firefox": System.setProperty("webdriver.gecko.driver", pathToDriver); returnere ny FirefoxDriver(); standard: System.setProperty("webdriver.chrome.driver", pathToDriver); returner ny ChromeDriver(); } } else { System.setProperty("webdriver.chrome.driver", pathToDriver); returner ny ChromeDriver(); } } private String getDriverPath(String browserName) { String osData = System.getProperty("os.name").toLowerCase().split("\\\\s")[0]; if (null != osData) { if (osData.equalsIgnoreCase("mac")) { return "./DriversExe/" + osData + "_" + browserName; } else if (osData.contains("nux") || (osData.contains("nix"))) { return "./DriversExe/linux_" + browserName; } else if (osData.contains("win")) { return "./DriversExe/" + osData + "_" + browserName + ".exe"; } } returner null; } }

Her er implementeringen af ​​klassen Remote Driver: 

pakke com.cyborg.core.web.utils.driverUtils; import org.openqa.selenium.WebDriver; import org.openqa.selenium.remote.DesiredCapabilities; import org.openqa.selenium.remote.RemoteWebDriver; import com.cyborg.core.generic.dataUtils.PropertiesDataUtils; import java.net.MalformedURLEException; importer java.net.URL; public class RemoteDriver implementerer IDriver { DesiredCapabilities caps; String remoteHuburl=PropertiesDataUtils.configDataStore.get("WEB_GRID_IP"); @Override public WebDriver init(String browserName) { if (browserName != null) { switch (browserName) { case "firefox": try { return new RemoteWebDriver(new URL(remoteHuburl), caps.firefox()); } catch (MalformedURLException malformedUrlEx) { malformedUrlEx.getCause().getMessage(); malformedUrlEx.printStackTrace(); } case "chrome": prøv { return new RemoteWebDriver(new URL(remoteHuburl), caps.chrome()); } catch (MalformedURLException malformedUrlEx) { malformedUrlEx.getCause().getMessage(); malformedUrlEx.printStackTrace(); } case "ie": prøv { return new RemoteWebDriver(ny URL(remoteHuburl), caps.internetExplorer()); } catch (MalformedURLException malformedUrlEx) { malformedUrlEx.getCause().getMessage(); malformedUrlEx.printStackTrace(); } standard: prøv { return new RemoteWebDriver(ny URL(remoteHuburl), caps.chrome()); } catch (MalformedURLException malformedUrlEx) { malformedUrlEx.getCause().getMessage(); malformedUrlEx.printStackTrace(); } } returner null; } else { return null; } }

Her er implementeringen af ​​fabriksklassen, som giver den respektive browser- og driverklasseobjekt: 

pakke com.cyborg.core.web.utils.driverUtils; public class DriverProvider { public IDriver getDriver(String typeOfDriver) { if (typeOfDriver != null) { switch (typeOfDriver) { case "local": return new LocalDriver(); case "remote": returner ny RemoteDriver(); standard: returner ny LocalDriver(); } } else { return null; } } }

På samme måde kan du implementere Appium driver sammen med det samme design, skal du blot give implementeringen og erklære en metode i IDriver-grænsefladerne. 

konklusion: Med dette konkluderer vi her, hvordan du kan bruge sprogdesignmønstre som en del af Selen-designmønstre og bedste praksis, mens du udvikler hybridrammerne i Selen; i de kommende segmenter af selvstudiet bygger vi Page Object-modelrammen til Selenium Automation.

At hente Samlet tutorial om Selen kan du besøge her

Efterlad en kommentar