Understanding DNS and localhost

The Domain Name System [DNS] is the system a browser uses to resolve domain names like generalchicken.net to IP addresses like 34.197.171.101. A server connected to the internet generally has one IP address, usually one main domain, but it can also have many subdomains. For instance, this server hosts the domains generalchicken.net and another blog, messagetothefish.com. Both have the same IP address, but different domain names.
When an HTTP or HTTPS request is sent to the server, the request should include the host header which indicates to the server what domain a resonse is expected from. A browser like Chrome or Firefox does this automatically for the user.
Internally, once the request is received by the server, a web server, like Apache, sends each request to a particular directory, based on what subdomain is named in the host header. From there, a file is activated, and in our case, passed to the PHP parser. For WordPress, it is called index.php. On most Ubuntu WordPress setups, the main domain root directory is usually set to:
//var/www/html/
and subdomains go from there:
//var/www/html/sub1/
//var/www/html/sub2/

These are the directories [for their respective domains], which will contain the WordPress root files, especially the index.php, the wp-config.php files, and the other directories like:
//var/www/html/wp-admin/
//var/www/html/wp-content/themes/
//var/www/html/wp-content/plugins/
//var/www/html/wp-includes/

Understanding this is important because if you are setting up a local development version of WordPress, you are going to want to be able to set subdomains up. Normally, you’ll have a sepearte wp-config.php file for each domain, specifying which database the domain points to.

The default setup on Ubuntu, is for the domain localhost to point to //var/www/html . Therefore, to access your local WordPress site, open a browser like Chrome, and got to http://localhost/ and you should get the WordPress install screen.

Another consideration is that most forms of testing work the best when you don’t have any state. That is, the database is either reset to a starting point, or totally scrubbed after each test. If you’re not used to this, you may accidentally delete anything you have on your site, especially if you’re using it for anything.

My personal setup is that I use http://localhost/ for unit testing, and I have another WordPress install, called http://laptop.dev/ where I have a database that doesn’t reset.

Directions: Setting up virtual hosts on Ubuntu 16.04 LTS.

Types of WordPress automated tests

state browser database SUT
WP Acceptance tests carries from test to test assumed headfull JS browser [ie. Selenium with Chrome] not reset after each test entire WP application executed with each browser call
Stateless acceptance tests tests run in isolation assumed headless JS browser [ie. PhantomJS] reset after each test entire WP application executed with each browser call
WP Unit tests tests run in isolation assume no browser or only cURL reset after each test WP application NOT executed
WP API tests tests run in isolation cURL only reset after each test WP application is executed

Live MasterMind BDD Group

Sign up to learn Behavior Driven Development in WordPress!

Hi! I’m John Dee. I’m the BDFL here at WordPress BDD. We have a MasterMind group to meet and do BDD in WP!

As a member of the MMG, you will have an opportunity to learn BDD in WordPress, and even get some free work done for your own projects. We take turns building classes and tests for each member of the MMG, so bring your development issues and we’ll solve them, the devops way!

We do a live screencast on Google Hangouts anytime I get 5 people who want to do TDD.

Topics:

  • Setting up CodeCeption for WordPress in the cloud
  • acceptance testing in WordPress
  • unit testing in WordPress
  • Gherkin feature files

Contact John to sign up!

e. johndeebdd@gmail.com
sms. (702)748-5491

Setup SSL on your website for $50/year

Get a Secure Sockets Layer (SSL) certificate INSTALLED for $50 a year.

CRG will setup, and manage, a Secure Sockets Layer (SSL) certificate on your website for only $50 a year. We use premium Electronic Frontier Foundation (EFF) certificates, just like the one on this website. Does it say “Secure” in green with a padlock next to your domain name, when you open it in a browser like Chrome or Firefox? If not, contact us right away. We can have you green in an hour!