Der Chrome zeigt während des Tests
Chrome is being controlled by automated test software
an? Das kann Dir die Click-Events verschieben (um etwa 100px nach oben) 🙄 Fix:
|
1 2 3 |
ChromeOptions options = new ChromeOptions(); options.addArguments("disable-infobars"); driver = new ChromeDriver(options); |
UPDATE: Ein paar Tage später sind die Koordinaten wieder verschoben; lag also nicht (nur?) daran!
Eine bessere Übersetzung Umschreibung für text-overflow ist mir nicht eingefallen 🙃
In jQuery ginge das so:
|
1 2 3 4 5 6 7 8 |
$.expr[':'].truncated = function (e) { // ggf. Style checken, bspw. // $(e).css('text-overflow') === 'ellipsis' return e.offsetWidth < e.scrollWidth; }; // dann: let items = $('.your-selector:truncated'); |
Cross-post; basiert auf den Antworten hier. Bonus: In Selenium geht das so:
|
1 2 3 4 5 6 7 8 9 10 |
WebElement element = ...; // element is truncated? double offsetWidth = Double.parseDouble(element.getAttribute("offsetWidth")); double scrollWidth = Double.parseDouble(element.getAttribute("scrollWidth")); assertThat(offsetWidth < scrollWidth).isTrue(); // truncation style is ellipsis? String overflowStyle = element.getCssValue("text-overflow"); assertThat(overflowStyle).isEqualTo("ellipsis"); |
bäm.
Wer mit Selenium Touchgesten simulieren will (hier: Pull-to-Refresh 🙂), der benötigt zuerst mal einen Browser, der Touch unterstützt:
|
1 2 3 4 5 6 7 8 9 10 |
Map<String, Object> someDeviceMetrics = ...; // see link Map<String, Object> emulation = new HashMap<>(); emulation.put("deviceMetrics", someDeviceMetrics); emulation.put("userAgent", "<some user agent>"); ChromeOptions options = new ChromeOptions(); options.setExperimentalOption("mobileEmulation", emulation); WebDriver driver = new RemoteWebDriver(SELENIUM_URL, options); |
Der Rest ist dann einfach:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
public class Browser implements HasTouchScreen, ... { // ... @Override public TouchScreen getTouch() {{ return driver instanceof HasTouchScreen ? ((HasTouchScreen) driver).getTouch() : new RemoteTouchScreen(new RemoteExecuteMethod((RemoteWebDriver) driver)); } } // ... // offsetX/offsetY = the distance to be panned new TouchActions(getBrowser()) .flick(target, offsetX, offsetY, 200) .perform(); |
(wenn man davon absieht, dass der vierte Parameter laut Sourcecode 0, 1 oder 2 sein sollte, nicht 200 – getestet mit selenium-java 3.9.1)
|
1 2 3 4 5 6 7 8 9 10 11 |
static boolean isInViewport(JavascriptInterface js, WebElement webElement) { Rectangle viewport = new Rectangle(0, 0, (int) js.exec("return \$(window).width()"), (int) js.exec("return \$(window).height()")) Rectangle element = new Rectangle( webElement.location.x, webElement.location.y, webElement.size.width, webElement.size.height) viewport.contains(element) } |
PS: viewport.intersects(element) würde prüfen, ob das Element mindestens teilweise im Viewport liegt.
Das ist tatsächlich nicht so trivial, aber der Reihe nach:
Wer danach googelt, findet erstaunlich (?) häufig den Ansatz, die URL auf endsWith(“.pdf”) zu prüfen 😳 Das sagt natürlich nichts darüber, ob das PDF auch dargestellt wird (oder ob es das richtige PDF ist), aber als erste Näherung habe ich das übernommen. Allerdings prüfe ich die URL etwas genauer, und vergleiche sie mit der URL, deren PDF-Ausgabe backendseitig bereits inhaltlich geprüft wird:
|
1 2 |
String expected = getBaseUrl() + "item/[0-9]+/print" url.matches(expected) |
Kurz hatte ich dann überlegt, auf den Content Type zu prüfen, aber da kann natürlich alles drin stehen. Die o.g. Bedingungen stellt das ebenfalls nicht sicher.
Dann gibt es Ansätze, STRG+A/STRG+C zu nutzen (Beispiel), um den Inhalt des PDF zu verifizieren – funktioniert nicht mit jedem OS/Browser.
Dann, ebenfalls häufig genannt: PDFBox. Finde ich gut, so kommt man an den Inhalt des PDFs und kann sicherstellen, dass es das richtige PDF ist:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
import org.apache.commons.codec.binary.Base64 import org.apache.pdfbox.pdmodel.PDDocument import org.apache.pdfbox.text.PDFTextStripper // test if there's a PDF at this URI: PDDocument pdf = getAsPDF(url) noExceptionThrown() pdf != null // and if the PDF seems to be valid: String text = extractTextFromPDF(pdf) text.contains("foo bar") // ... mit: PDDocument getAsPDF(String theUrl) throws Exception { // bonus points: The end point needs authentification :-) byte[] credentials = new Base64().encode("admin:admin".getBytes()) String basicAuth = "Basic " + new String(credentials) URL url = new URL(theUrl) URLConnection uc = url.openConnection() uc.setRequestProperty("Authorization", basicAuth) PDDocument.load(uc.getInputStream()) } String extractTextFromPDF(PDDocument pdf) { PDFTextStripper pdfStripper = new PDFTextStripper() pdfStripper.setStartPage(1) // 1-based pdfStripper.setEndPage(pdf.getPages().count) // inclusive pdfStripper.getText(pdf) } |
Nachteil: Dass die URL [ein|das richtige] PDF ausliefert, sagt natürlich nichts darüber, dass das im Browser dargestellt wird 🙃
Also: Screenshot machen. Allerdings nicht die Selenium-Methode, denn aus Browser-Sicht ist die Seite “leer”, das PDF wird von einem Plugin gerendert. Die Lösung dazu: Robot.
ACHTUNG: Das geht nicht in einer “headless”-Umgebung, wie man sie bsplw. auf vielen CI-Servern findet:
java.awt.AWTException: headless environment
Mit einem waitFor, bis das PDF tatsächlich gerendert wurde (denn das ist ungleich “die Seite wurde geladen”):
|
1 2 3 4 5 6 |
BufferedImage screenshot = null waitFor { screenshot = getScreenshot(driver) !new Color(screenshot.getRGB(100, 100)).equals(Color.white) } |
und einem kleinen Trick, um statt des Bildschirms nur den Browserinhalt zu screenshoten:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
static Rectangle getWindowRectangle(WebDriver driver) { WebDriver.Window window = driver.manage().window() new Rectangle( window.position.x, window.position.y, window.size.width, window.size.height ) } /** * Works with PDF etc as well. */ static BufferedImage getScreenshot(WebDriver driver) { new Robot().createScreenCapture(getWindowRectangle(driver)); } |
Auf Basis des Bildes kann man nun sicherstellen, dass keine weiße Seite gerendert wurde…
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
boolean foundRefColor1 = false boolean foundRefColor2 = false for (int x = 0; x < screenshot.width; x++) { for (int y = 0; y < screenshot.height; y++) { Color current = new Color(screenshot.getRGB(x, y)) if (!foundRefColor1 && current.equals(COLOR_1)) { foundRefColor1 = true break } else if (!foundRefColor2 && current.equals(COLOR_2)) { foundRefColor2 = true break } } if (foundRefColor1 && foundRefColor2) { break } } foundRefColor1 && foundRefColor2 |
…oder halt irgendwas. Man könnte auch PNG-Vergleiche machen. Inhaltlich, wie gesagt, würde man mit PDFBox testen, darum ging es hier aber nicht.
HTH.
Wer bsplw. Selenium gegen den IE fährt, der wird auf den “Protected Mode” stoßen, doch wer den per Skript setzen will, der muss schon etwas länger suchen: In der Registry gibt es einen entsprechenden Schlüssel “2500” (“Turn on Protected Mode”).
Dazu:
Unless stated otherwise, each DWORD value is equal to zero, one, or three. Typically, a setting of zero sets a specific action as permitted, a setting of one causes a prompt to appear, and a setting of three prohibits the specific action.
In Code sieht das dann so aus:
|
1 |
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\4" /v 2500 /t REG_DWORD /d 0 /f |
Danke, Johann!
EDIT: Scheint nicht (persistent) zu funktionieren. Ein Workaround scheint
|
1 |
INTRODUCE_FLAKINESS_BY_IGNORING_SECURITY_DOMAINS |
zu sein, und dies könnte man auch probieren:
For IE 11 only, you will need to set a registry entry on the target computer so that the driver can maintain a connection to the instance of Internet Explorer it creates.
For 32-bit Windows installations, the key you must examine in the registry editor is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BFCACHE.
For 64-bit Windows installations, the key is HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BFCACHE.
Please note that the FEATURE_BFCACHE subkey may or may not be present, and should be created if it is not present.
Important: Inside this key, create a DWORD value named iexplore.exe with the value of 0.