<commit_before><!doctype html>
<meta charset=utf-8>
<title>Worst practices</title>
<link rel="icon" href="favicon.ico" type="image/vnd.microsoft.icon">
<link rel="shortcut icon" href="favicon.ico" type="image/vnd.microsoft.icon">
<link rel=stylesheet href=se.css>
<link rel=prev href=best.html title="Best practices">
<link rel=next href=grid.html title=Grid>
<script src=docs.js></script>

<h1>Worst practices</h1>


<h2>Captchas</h2>

<p>CAPTCHA, short for <em>Completely Automated Public Turing test
 to tell Computers and Humans Apart</em>,
 are explicitly designed to prevent automation, so don’t try!
 There are two primary strategies to get around CAPTCHA checks:

<ul>
 <li>Disable CAPTCHAs in your test environment
 <li>Add a hook to allow tests to bypass the CAPTCHA
</ul>


<h2>File downloads</h2>

<p>Whilst it is possible to start a download
 by clicking a link with a browser under Selenium's control,
 the API does not expose download progress,
 making it less than idea for testing downloaded files.
 This is because downloading files is not considered an important aspect
 of emulating user interaction with the web platform.
 Instead, find the link using Selenium
 (and any required cookies)
 and pass it to a HTTP request library like
 <a href=https://curl.haxx.se/libcurl/>libcurl</a>.


<h2>HTTP response codes</h2>

<p>For some browser configurations in Selenium RC, Selenium acted as a
proxy between the browser and the site being automated.  This meant
that all browser traffic passed through Selenium could be
captured or manipulated.  The <code>captureNetworkTraffic()</code> method
purported to capture all of the network traffic between the browser
and the site being automated, including HTTP response codes.

<p>Selenium WebDriver is a completely different approach to browser
automation, preferring to act more like a user and this is represented
in the way you write tests with WebDriver.  In automated functional
testing, checking the status code is not a particularly important
detail of a test's failure; the steps that preceded it are more
important.

<p>The browser will always represent the HTTP status code, imagine for
example a 404 or a 500 error page.  A simple way to “fail fast” when
you encounter one of these error pages is to check the page title or
content of a reliable point (e.g. the &lt;h1&gt; tag) after every page
load.  If you are using the page object model you can include this
check in your class constructor or similar point where the page load
is expected.  Occasionally the HTTP code may even be represented in
the browser's error page and you could use WebDriver to read this and
improve your debugging output.

<p>Checking the webpage itself is inline with WebDriver's ideal practice
of representing and asserting upon the user's view of the website.

<p>If you insist, an advanced solution to capturing HTTP status codes is
to replicate the behavior of Selenium RC by using a proxy.  WebDriver
API provides the ability to set a proxy for the browser, and there are
a number of proxies that programmatically allow you to manipulate the
contents of requests sent to and received from the web server.  Using
a proxy lets you decide how you want to respond to redirection
response codes.  Additionally, not every browser makes the response
codes available to WebDriver, so opting to use a proxy allows you to
have a solution that works for every browser.<commit_msg>worst: reformat http response codes<commit_after><!doctype html>
<meta charset=utf-8>
<title>Worst practices</title>
<link rel="icon" href="favicon.ico" type="image/vnd.microsoft.icon">
<link rel="shortcut icon" href="favicon.ico" type="image/vnd.microsoft.icon">
<link rel=stylesheet href=se.css>
<link rel=prev href=best.html title="Best practices">
<link rel=next href=grid.html title=Grid>
<script src=docs.js></script>

<h1>Worst practices</h1>


<h2>Captchas</h2>

<p>CAPTCHA, short for <em>Completely Automated Public Turing test
 to tell Computers and Humans Apart</em>,
 are explicitly designed to prevent automation, so don’t try!
 There are two primary strategies to get around CAPTCHA checks:

<ul>
 <li>Disable CAPTCHAs in your test environment
 <li>Add a hook to allow tests to bypass the CAPTCHA
</ul>


<h2>File downloads</h2>

<p>Whilst it is possible to start a download
 by clicking a link with a browser under Selenium's control,
 the API does not expose download progress,
 making it less than idea for testing downloaded files.
 This is because downloading files is not considered an important aspect
 of emulating user interaction with the web platform.
 Instead, find the link using Selenium
 (and any required cookies)
 and pass it to a HTTP request library like
 <a href=https://curl.haxx.se/libcurl/>libcurl</a>.


<h2>HTTP response codes</h2>

<p>For some browser configurations in Selenium RC,
 Selenium acted as a proxy between the browser
 and the site being automated.
 This meant that all browser traffic passed through Selenium
 could be captured or manipulated.
 The <code>captureNetworkTraffic()</code> method
 purported to capture all of the network traffic between the browser
 and the site being automated,
 including HTTP response codes.

<p>Selenium WebDriver is a completely different approach
 to browser automation,
 preferring to act more like a user
 and this is represented in the way you write tests with WebDriver.
 In automated functional testing,
 checking the status code
 is not a particularly important detail of a test's failure;
 the steps that preceded it are more important.

<p>The browser will always represent the HTTP status code,
 imagine for example a 404 or a 500 error page.
 A simple way to “fail fast” when you encounter one of these error pages
 is to check the page title or content of a reliable point
 (e.g. the &lt;h1&gt; tag) after every page load.
 If you are using the page object model
 you can include this check in your class constructor
 or similar point where the page load is expected.
 Occasionally the HTTP code may even be represented
 in the browser's error page
 and you could use WebDriver to read this
 and improve your debugging output.

<p>Checking the webpage itself is in line
 with WebDriver's ideal practice
 of representing and asserting upon the user’s view of the website.

<p>If you insist, an advanced solution to capturing HTTP status codes
 is to replicate the behaviour of Selenium RC by using a proxy.
 WebDriver API provides the ability to set a proxy for the browser,
 and there are a number of proxies that will
 programmatically allow you to manipulate
 the contents of requests sent to and received from the web server.
 Using a proxy lets you decide how you want to respond
 to redirection response codes.
 Additionally, not every browser
 makes the response codes available to WebDriver,
 so opting to use a proxy
 allows you to have a solution that works for every browser.
{'fraction_non_alphanumeric': 0.05570829113008248, 'fraction_numerical': 0.004630299522500362, 'mean_word_length': 4.698268755152514, 'pattern_counts': {'":': 0, '<': 75, '<?xml version=': 0, '>': 75, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 10, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1291690', 'n_tokens_mistral': 1894, 'n_tokens_neox': 1777, 'n_words': 1011}