È una cattiva pratica restituire il riferimento di terze parti dal metodo pubblico?

2

Consideriamo un esempio da WebDriver in cui creo due classi diverse per gestire l'oggetto pagina, uno memorizza il localizzatore di elementi e altre operazioni reali che riguardano la pagina -

public class ContactPageElements  {
   private By nameTextBox = By.id("name");

   public static By getNameLocator() {
      return nameTextBox;
   }
}


public class ContactPage  {
  public ContactPage enterName(String name) {      
    findElement(ContactPageElements.getNameLocator()).sendKeys(name);
    return this;
  }
}

Ora, se dovessi sostituire WebDriver con un nuovo framework di test snazy, interromperò la classe ContactPage poiché dipende dall'oggetto By che viene restituito dalla classe ContactPageElements.

Quindi mi sembra che la classe ContactPageElements non debba avere un metodo pubblico che restituisce Per oggetto. Ma allora quale opzione mi è rimasta?

Sono titubante nel mantenere gli elementi locator nella percentuale diContactPage in quanto potrei finire per violare il principio di responsabilità singola.

    
posta Tarun 24.03.2016 - 10:04
fonte

2 risposte

3

Hai ragione a essere titubante a divulgare i tipi di libreria di terze parti su tutto il tuo codice.

Hai anche ragione nel voler mantenere le tue lezioni focalizzate e al punto.

Il modo in cui ti aggiri è nascondendo la libreria di terze parti dietro una "API" che codifichi e ti mantenga. Puoi farlo mettendo a buon uso gli adattatori e / o la facciata. Sì, significherà un codice extra, essenzialmente un "layer" extra che non fa molto di più che passare alla libreria di terze parti, ma ti dà il meglio di entrambi i mondi.

Come ho detto in un commento su Dovrei scrivere un'interfaccia API prima di un'implementazione? :

Wrapping third party libraries isn't a YAGNI violation, but a much needed protection against "third party library infestation of your own code". It is not just about being able to swap out a library, but as MetaFight also says a defense against changes in newer versions of the library which would otherwise require changes throughout your own code. By wrapping the library (and especially its specific types: classes, enums, structs etc), you insulate your own code and have a single point to change when the library changes (for whatever reason).

    
risposta data 24.03.2016 - 13:11
fonte
3

Potresti usare una facciata, qualcosa di simile

public interface ILocator { ... }

public interface IElementFinder {
  findElement(ILocator loc)
}

Dovresti estrarre tutte le funzionalità generali rilevanti dal selenio per creare le interfacce corrette e quindi implementarle come un sottile strato.

Questo ha un paio di aspetti negativi - YAGNI come il primo, ma anche il fatto che parti specifiche della tua libreria potrebbero dipendere (in senso buono) dal modo in cui parti specifiche della libreria funzionano.

Un modo forse migliore sarebbe estrarre tutto il codice specifico del selenio, usarlo nella propria libreria e nasconderlo dietro un'interfaccia.

Ad esempio

interface IYourTestImplementation {...}
class SeleniumTestImplementation : IYourTestImplementation {...} 
    
risposta data 24.03.2016 - 13:16
fonte

Leggi altre domande sui tag