Page Object Model testing

In the ongoing process of doing my code work on my Github, I came across an idea that I’d actually encountered before. But it was one for which I’d never previously had an identifying term, and I was excited to learn about this.

Namely, Page Object Model testing. (Not to be confused with Project Object Model, which is what the POM in a pom.xml file stands for when you’re working with Maven.)

What this is: a way of writing a test framework that separates “code that represents the thing you’re testing” from “code that actually does the testing”. Turns out I’d learned about how to do this at Big Fish, when I picked up the idea and how to implement in Python.

Back in those days, it helped to do this because it let me have test cases that basically said “okay go get me the page I need to test, and stick all the data representing it into this object, which I will then do tests against”. It meant that in setup for tests, all I had to do was go grab an instance of the object that represented the page to be tested. And that meant in turn that the tests themselves were more tightly focused.

I found that it required a bit more organizational work to set up, but that once I had the idea in place, it meant writing future tests became easier. For example, if I had test script A that tested the homepage of the site, and then later needed to write test script B against the same page, I wouldn’t have to rewrite the code that loaded the homepage for testing. Likewise, if something about the structure of the homepage changed, I would only have to change the class that dictated that structure, with possibly only minor changes to any test scripts that needed to deal with it.

I liked this way of organizing code well enough that I have been implementing it on my Github repos. In the Python Selenium demo, specifically.

But, now that I’m done with the initial wave of Selenium tests and am looking at ways to expand the suite in both Java and Python, I started thinking of how to rearrange the organizational structure of both suites and seeing whether I could do a similar structure in Java. That led me to discovering that this whole concept had a name.

And it also led me to being able to implement Page Object Model testing in the Java Selenium repo, too.

What this means in practical terms is that I can think of pages on my test WordPress site in terms of “here is an object that represents an entire page, including child objects”. These child objects would be things that are shared across all pages, like a sidebar, or a footer, or a menu. Their various objects are things I have to implement only once in a Page Object Model system, and then use as necessary in tests that actually look at them on different pages.

So all in all this has been a satisfying area of research.

Some links I’ve used to read up about this:

Page Object Model (POM) | Design Pattern on Medium.com

Getting Started with Page Object Pattern for Your Selenium Tests on Pluralsight.com

A few quick definitions

Regarding the last post I put up (here if you’re reading this on annathepiper.org, and here if you’re reading it on Dreamwidth), I thought I’d do another quick post with some definitions of terms I’m throwing around, for those of you who aren’t in the tech industry and might not know what I’m talking about:

API: An API is basically a known set of ways that a program, operating system, or in this case a website makes available for others to hook into and use. For example, Apple has an API for developers to use if they want to create apps for iOS. What I’m doing is playing with the REST API that WordPress makes available as part of the WordPress code.

Service: A service is a thing that sits underneath a website and does a lot of under-the-hood things for it. I described this on Facebook as being part of a website’s engine. It’s not something a user would see just interacting with a site in their browser, but it’s an important thing nonetheless, and it’s there to help the website do its job.

REST API: REST is specifically one type of format an API might take for access to a web service. This Wikipedia page has more if you want to read up on it. But for purposes of this post, I’ll simply say that the REST API endpoints I’ve worked with to date, both in the context of a job and on my personal coding projects, are endpoints that return JSON payloads that I can test against.

JSON: JSON is a file format with a specific syntax and structure. It gets used a lot in web services as it’s reasonably easy to parse, as well as hand back and forth through various steps of a web site’s operation. So when I see a JSON payload come back off a web service endpoint, I can use my test automation to analyze that payload and look for interesting things in it. For example, an HTTP response code, like a 404. Or an error message or error code. OR, if the test is specifically looking for a successful response, I might be looking for an expected title or body of content. Since I know I’m dealing with JSON, I can set up my code to drill down into the payload and look for these specific things.

Endpoint: An endpoint is basically one of several routes you can use to do things with a service. It’s more or less a URL that you can use to make the service report back on various things.

So with all of those identified, does it make more sense now if I say that my demo tests are hitting the documented WordPress REST API endpoints, looking at the JSON I can get back from those endpoints, and analyzing them for various things? Let me know! And let me know if you have any questions. :)

Negative test cases

On a previous job interview loop, one of the people I spoke with gave me good feedback about the work I’ve been putting up on my Github repos. He observed at the time that I had been hitting the low-hanging fruit: i.e., the test cases dealing with good, expected data.

He was right. So I’ve gone back and updated my repos for the WordPress REST API tests to also include negative test cases, i.e., known bad data, to test the error behavior of the endpoints. So here’s what I focused on to do that.

First, several of the endpoints ask for IDs of this, that, and the other thing: post IDs, category IDs, etc. For those sorts of cases, I did these negative tests:

  • IDs that could be valid (i.e., were legit integers), but which did not actually exist as posts.
  • IDs that were specifically not valid, i.e., things that were not integers. E.g., “aaaaaaa”.
  • Using MAXINT as a post ID, just to use a GIGANTIC integer. Practically speaking I’d usually expect this to also be a “this post does not exist” scenario. But I’ve tested things in the past where throwing a thing a value slightly above a limit behaved, but throwing it a value WAY bigger than the limit did not. So I wanted to do this scenario too.
  • Also using MININT as a post ID. This is not only to test using a gigantic thing, but ALSO to test using a gigantic thing that could not actually be a valid post ID (i.e., because it’s a negative number).

Secondly, several of the rest of the endpoints didn’t use IDs, but rather, slug/tags. So for those endpoints, I did negative test cases that were very similar.

  • Slugs/tags that could be valid, i.e., strings, but which did not actually exist in the database (such as using “pancakes” for a category tag).
  • Slugs/tags that could not be valid. E.g., using “pancakes” with additional non-alphabetic characters.
  • Using MAXINT and MININT again.

In all of these cases, I threw the bad data at the endpoints and looked for specific error codes and error messages I was expecting to get in response. I also looked for 404 response codes.

I got the expected behavior by testing the various endpoints manually with bad data, in Postman, and seeing how they responded. That gave me the basic JSON response structure I would need to expect: that there would be both an error code and an error message, and an additional data object that would contain the response code within it. So my test cases looked for all three of these things.

As of this writing, I’ve implemented the negative test cases in Java, Python, and C#. Once I had them working in Java, it was reasonably easy to port them over to the other languages. In all three languages, this has now brought the test case count for the REST API suite from 20 up to 60.

In addition to learning the error behavior of the various endpoints, the most useful thing I’ve picked up on in this part of the project is how to get at MAXINT and MININT in the various languages.

In Java, it’s Integer.MAX_VALUE and Integer.MIN_VALUE. In Python, it’s sys.maxsize or -sys.maxsize–and this is Python 3, specifically. (Apparently, in Python 2, it was sys.maxint, but it changed; if I understand the change correctly, it was because Python 3 doesn’t have a hard and fast integer size limit, because it automatically recasts your number to a long on the fly if you go over the theoretical int limit.) And in C#, it’s int.MaxValue and int.MinValue.

Meanwhile, over in the Selenium test suites, there are fewer opportunities there for negative cases. But I did add some there that throw bad data at the search box, to verify that I get the appropriate messaging if there are no matching results. There’s some room for expansion there as well, to try to test the limits of what the search box can accept. So that’ll be the next place I add more negative cases.

Porting my projects to C#

Back in Ye Olden Times when I went to college, object-oriented programming was barely starting to become a thing. It didn’t help matters that the particular school I went to was behind the times on its computer science program, either. So I didn’t discover until I was actually in the workforce that of all the languages I’d learned about in college, the only one that was at all useful was C.

C# hadn’t been invented yet when I graduated. When I look it up, I see that Microsoft put out the first release of C# around 2000 (source: Wikipedia’s C# page), and by then, I was working at Attachmate. Attachmate was one of the last times I had any opportunity to work with C++, aside from one short contract I had after they laid me off.

Up till then, my only work at Microsoft (my full-time stint there in the early 90’s, and my contract work in the mid-90’s), was pre-C#. My next work at Microsoft, the two back-to-back contracts I had from 2003 to 2005, was straight up testing: a mix of manual testing and running automation written by the team’s actual employees. I didn’t have any opportunity to work with any language directly myself, much less C#.

After that, all of the full time gigs I’ve had were ones functioning outside the Microsoft-based ecosystem. Big Fish in particular was a Python and Java environment. Which has been great for my accrual of Java and Python experience!

But now that I’m back on the job market, I’m seeing regular signs of jobs asking for C# coming across my radar. So far, I’ve had to tell recruiters that I don’t have any professional experience working with the language, or for that matter with modern versions of Visual Studio. (The last time I would have seen any version of Visual Studio would have been that aforementioned short contract. According to my old resumes, round about then, I was mentioning working with Visual Studio 6.0 and Visual Studio .NET.)

I figured, though, that as long as I have time on my hands it would behoove me to try to actually get some hands-on experience with the current release of Visual Studio and with C#. And, since I’ve been told by former Big Fish colleagues that C# is very, very similar to Java overall, I figured I’d try to port my current Java work up on Github over into C#.

As of this writing, I have done this! The code I’ve ported so far is the little test suite that runs the REST API tests against my test WordPress site. This ported code now lives on my Github in its own repo.

Things I have learned from this experience

I do not like Visual Studio as much as I do IntelliJ for an IDE. But since part of this entire point was to practice getting hands-on experience with a current Visual Studio version, I put up with that. And it helped that I figured out a few ways to make Visual Studio less cluttered, by docking the things I need access to off on the side to be hidden until I need them. That frees up most of the screen on my dev laptop for me to see my code.

C# is, indeed, a LOT like Java. It’s simultaneously enough like Java and enough different from Java that the little differences will probably catch me up a lot if I wind up regularly working with this language. Nothing I couldn’t eventually get used to. But it’ll be a thing I’ll need to look out for.

I don’t like that Visual Studio makes me have to re-add a file in git every time I change it. (IntelliJ does not make me do this, even on Windows.) When I went googling about this, I found that this is apparently by design.

I do like the concept of a “namespace” that’s apparently a thing in C#. If I understand it correctly, the idea here is to have a big set of associated files. This seems to simplify matters a bit, and has saved me having to do a few extra import statements.

Oh wait, I’m sorry, not “import”. “Using”. See previous commentary re: differences between C# and Java.

Something else I’m still having to get used to, and this is a question of “quirks of the IDE” as opposed to “quirks of the language”: if I want to run tests in Visual Studio, I have to hit the Test Explorer for that. I can’t build the project directly, otherwise it’ll complain at me. This seems to be because I’ve built my various test classes as class libraries, as per various tutorials I’ve seen on how to set up tests. Which means in turn that Visual Studio won’t let me run them directly. Apparently you only get to run things in Visual Studio if you’re specifically building executables?

Lastly, a quibble of terminology: I don’t like that Visual Studio calls its projects “solutions”. It’s a bit too rah-rah YAY GO SOLVE YOUR PROBLEM for me. And I’m all “yes yes I’m going to STOP TRYING TOO HARD TO HELP ME”, here.

Which, I feel, exemplifies my experience with Microsoft products overall rather well.

Specific libraries I’ve discovered

A lot of this porting work has been “learn how to deal with the language” as well as “learn how to deal with the IDE”. But there’s also been some measure of “find C# equivalents of the technology I’m used to dealing with in Java”. One of these has been TestNG. The recommended C# version of this is apparently NUnit, which seems fine so far. Learning how to deal with this has been just a question of learning its specific syntax for annotating test methods.

Likewise, the current recommended way of doing REST API testing in C# seems to be RestSharp. From what I saw in my googling, apparently there’s now an in-language way of doing this, but I stuck with RestSharp as it seemed a good analog of the Unirest library I learned how to use on the Java side.

Lastly, since I needed to find an equivalent for how Java parses JSON, I went with LINQ to JSON in the JSON.NET/Newtonsoft library. This has been a pretty close match to the json.org libraries you can use in Java, and gives me the same level of ability to parse JSON payloads without having to worry about deserializing them.

(Which took me a bit of work to discover. RestSharp’s docs seemed to really really REALLY want me to deserialize JSON I get back on REST API calls. This is not helpful if all I really want to do is look into the JSON and go “yes, I see the correct value(s) in there”, as opposed to actually saving the stuff out into variables and doing additional things with it.)

What’s next

I also want to port the Selenium-based tests into C#. But since the Java version of these tests specifically uses Selenide as a framework to do its testing, I want to find a C# library that does the same thing. Atata seems promising and I shall investigate it.

Tutorials I’ve found so far for how to do Selenium-based testing in C# talk a lot about how to install Selenium and browser drivers into your Visual Studio. I don’t actually need to do that, given that I already have a Docker grid running. And since I already know how Selenium works, all I really need to know is how to get my C# code pointed at a Selenium grid.

Job descriptions that come across my radar also keep periodically mentioning Cucumber. This is a thing I discovered during my last research project at Big Fish, so I’ve been a bit interested in checking it out. I don’t know yet how well it plays with C#. This may also require investigation.

All in all

This has been a valuable experience so far. I can now say with assurance that if called upon to do so, I can in fact deal with both C# and Visual Studio.

Under no circumstances can I be called an expert, mind you. And I would still not be a good job match for any position that requires multiple years of experience working in the C# realm. But for any position with a bit more flexibility, where they’d be willing to go “oh sure, you have experience with Java and Python and have at least SEEN C#? We can work with this”? I could do that.

Also: given that I’m an amateur musician, I do have to say, I do like that the language is called C#. I play that note a lot on my fiddle and on my winds. I’ll take any little connection to music in this endeavor that I can get. :D

Coding projects update

As of this writing, I now have a total of five repositories on my Github account: the misc-configs repo for various config/supplementary files, and two each for Java and Python work. For each of those languages, I have a repo for the REST API portion of this project, and one for the Selenium.

All of the repos can be seen on my Github account.

What I’ve been calling the rough “phase 1” of this project is now more or less complete. I’ve got basic test cases in place in both languages for both the REST API side, and the Selenium side. As I’ve written about before, the API tests are dealing with the service endpoints that handle publicly viewable information. The Selenium tests are mostly oriented around testing parts of the homepage of my little test WordPress site.

Now I’m moving into the rough “phase 2”. In this phase, I’m adding more Selenium tests. This’ll include adding some sidebar tests for the homepage, as well as tests for additional sections of the site (a post and a page), and making sure that the elements are correct on the selected links. I’ll also be testing site search and adding a new comment to a previously existing post, since that’s something I can do without authentication.

“Phase 3” of this project will get into dealing with stuff that requires authentication. From the REST API side, this’ll mean dealing with the service endpoints that handle things at the site admin level (such as making a new post or comment, or editing a previously existing one). From the Selenium side, I’ll want to see about verifying logging in and logging out of the site, and making sure that the links displayed in the “META” area of the sidebar update themselves accordingly.

(NOTE: I am NOT going to try to test the actual WordPress admin UI. That’s a whole different kettle of fish than testing a front-facing site.)

In related news, I’ve also discovered the Githubs “Projects” functionality, and I’ve made myself a project there to cover the work I’m doing. This amuses me, as their Projects board looks a lot like JIRA, the bug tracking/project management software we used at my Former Day Job, as well as at the short contract I had after the layoff at the tail end of last year.

Interested parties can find my current active project on my Github projects page. I’ll be adding additional projects to that once this one is complete–like the WordPress plugin work I want to do!

I’ve actually had job recruiters and interviewers ask me about this work, now that I’ve got a link to my Github on my resume. This has proven beneficial in interviews I had last week, and I even got useful tips on additional libraries I can research, as well as aspects of version 8 of Java I hadn’t had experience with yet. I’ve gotten positive feedback about how I do comments on things, as well as on the various Readmes I’ve put on the repos.

So while the work hasn’t yet actually proven critical in landing me a job, it has proven useful in helping me demonstrate that I not only know how to code, but that I like it well enough to do it on my own time and to plan out larger projects.

This is, I feel, a very valuable thing for me to be able to demonstrate.

Coding projects update

I now have three active repositories up on my Github account. These are:

misc-configs: This one is for miscellaneous config files that are useful for the tests in the other repositories. What’s in here will mostly make sense to you if you are familiar with a) how to import data into a WordPress site, b) how to import Collections or Environment files into Postman, and/or c) how to use a YAML file to run Docker Compose to launch one or more containers.

wp-test-demo-java: This one is for my demo of testing the REST API endpoints made available by WordPress for any given site. Phase 1 of the work on this demo is complete, in which I test against the endpoints that handle publicly accessible data. I.e., the kinds of things you could find out about a WordPress site if you’re just a visitor to the site.

wp-test-demo-java-selenium: This demo is also using my test WordPress site, but here, I am doing front end testing rather than service testing. I’m using the Selenide Java library to run tests against the site via Selenium, a widely used automation framework for testing web pages. Selenide is a layer on top of Selenium that does the heavy lifting of Selenium setup for me, and frees me up to focus on the test cases I want to run.

This is a work in progress, but as of this post it has 27 test cases in it. There are more to come.

Other projects that’ll be showing up on my Github account include:

  • Phase 2 of the REST API project, which would involve hitting service endpoints that specifically require authentication.
  • Porting the Selenium tests over into Python, and structuring them in such a way as to be similar to the Python test framework we used on my former team at Big Fish. The intent here would be to demonstrate my ability to use Selenium in Python, and to write up a framework for it. (Which will require more work than the equivalent testing in Java!)
  • The teeny WordPress plugin I want to do that’ll make nice Dreamwidth-style user and community name tags in a post or page for me. (This is the one I’ve mentioned before that would be an expansion on the very old plugin that does this for LJ user and community tags.) This would be written in PHP, and the intent HERE would be to show my comfort level with PHP. I haven’t used this language as much in a professional context, but I HAVE used it a lot over the years dealing with my websites, and I can demonstrate that here.

Stretch goals:

  • Do something in JavaScript. What, I don’t know yet, but the obvious possibility would be to port some or all of the previously mentioned Selenium tests.
  • Since I do have a locally running plugin on annathepiper.org that fuels my Roleplay Logs page, time permitting, I’d like to do a more solid version of that. Right now the plugin I’m running is a hack of the previous non-Wordpress-based code, and it talks to a database outside the WordPress structure. A cleaner version of this would actually be properly integrated with WordPress. If I get really fancy, I could do an entry form in the Admin UI for WordPress to allow the addition of new logs, and possibly even reading them in via the Media section of the site. This would, of course, also be written in PHP. More on this as events warrant!

Today’s WordPress Test Demo update

Good progress on the coding project today! \0/ Things accomplished:

  • Added new test cases involving Categories, Tags, Pages, and Comments, to bring the total number of test cases up to 10
  • Added the ability to run the cases via a Maven configuration as well as TestNG, and updated my pom.xml to use the testng.xml as its suite file
  • Checked all the new test cases and related work into wp-test-demo-java
  • Renamed my wordpress-dev repo to misc-configs, because that’s really what it’s for miscellaneous config files
  • Updated my Postman collection to include all the endpoints for the test cases I wrote today, and checked the new version of that into misc-configs
  • Updated the Readmes on both wp-test-demo-java and misc-configs to more clearly explain what the repos are for, particularly wp-test-demo-java, as I’ll be pointing recruiters at that
  • Installed Jenkins (again) on my dev laptop, so that I can run the automation as a local Jenkins job as well as within IntelliJ, and to keep up my practice using Jenkins

I have decided, too, that I’ll be doing this project in phases.

Phase 1: REST API tests that hit the endpoints that can serve up publicly available data. I.e., the kinds of data you’d see as a user just browsing a WordPress site.

Phase 2: Selenium-based tests that will do front-end type tests. For example, “If I click on this link, does it take me to this expected target page?” Or, “If I click on this thing on the menu, do I get the correct dropdown off of it?”

Phase 3: This is the ambitious part. There are also REST API endpoints for WordPress that’ll let you get at the stuff you’d ONLY see as an authenticated user, such as post revisions and settings and the like. Time permitting, I may learn about the various ways to actually do that authentication properly so that the test suite can actually get at those endpoints.

Right now, though, I’m going to focus on phases 1 and 2.

The WordPress testing demo project is now underway

Spent most of today (very roughly during ‘work’ hours, just to try to keep to the whole idea of coding to a schedule) working on the WordPress testing demo project I talked about in my last post. As of this writing, I have some actual working things checked in up on Github. There’s only one functional test case so far, but it’s a start!

What I accomplished today:

  • Creating a Github repo for this work
  • Read about the API endpoints that WordPress makes available for any given site, some of which are publicly viewable, others of which require you to log in as a valid user
  • Started a Postman Collection to keep track of the endpoints I’ll be playing with for my test site, and checked an initial version of this in on Github
  • Refreshed my memory about how Unirest works, as this was the library we used at Big Fish to talk to various services; maybe not the most current library to use, but it’s the one I know, so I’m going with this for demo purposes
  • Got IntelliJ on the Linux partition of my dev laptop updated to the latest version
  • Built the actual project in IntelliJ, as a Maven project, so it’d have the correct file structure and a pom.xml file I could add dependencies to
  • Started building a client class that will use Unirest to hit those endpoints for my local test site
  • Built a BaseTest class in charge of doing setup used by all the test classes I’ll be making
  • Built a TestPosts class to start the test cases for the “Posts” endpoints in the aforementioned API, and now it even has an initial functional test case!

Now that I have an actual working (if tiny) framework here, I should be able to fill in some test cases reasonably quickly.

Note also that the test suite assumes I am running the WordPress test site locally. For bonus usefulness I should make some sort of healthcheck test case that verifies that the test site is in fact UP.

Further planning for doing my coding demo project

Since I continue to have time on my hands and no active leads bringing me in for interviews this coming week (so far), I’m moving forward with laying down the plans for my coding demo.

As I said in my last post about this (here for those of you reading on Dreamwidth), I’ve succeeded in setting up a test WordPress site in Docker.

The rest of this operation is going to look something like this, at least for phase 1 of this project:

  • Actually get some content into that test WordPress site. This will probably involve just doing a database copy down from my backup WordPress site up on angelahighland.wordpress.com. If for some reason I can’t do that, I’ll install a lorem ipsum generator plugin (there are a few for WordPress, I looked) and generate purely random content.
  • Study up on the REST API WordPress makes available for any given install.
  • Once I know what service endpoints are available, use that to scope out what test cases I can do.
  • Write out those test cases in a Java BVT suite, similar to the ones I wrote at Big Fish. Tools I will need for this: IntelliJ, TestNG.

A possible Phase 2 for this project will involve extending the testing to include front-end testing. In other words (for those of you unfamiliar with how web testing works), hitting the pages of the test site in a browser and verifying that expected things are there, and/or that you are able to do certain things (e.g., log in, do a search, leave a comment). Tools I will need for this: Selenium (also in a Docker image), with a side helping of the Selenide framework. This would be a followup on my previous research that I did as one of my last projects at Big Fish.

Possible stretch goal: replicate some of the same test cases in Python, just to brush up on my Python skills. Tools I’d be using in this part of the work: PyCharm.

I’ve been writing out some tasks for myself in Things, by way of a task breakdown, and I suppose this blog post kind of counts as a spec. Ha. :D

And when I’ve got some actual code, I’ll be checking it in on my personal Github account. This will be fun, hopefully, as well as a way to keep my skills active until such time as I can convince somebody to give me another job!

(EDITING TO ADD: This, by the way, is a separate project I’m planning in addition to doing a WordPress plugin! So I’ll have multiple things I can eventually point at by way of demonstrating I can code. What I’m talking about in this post is more along the lines of demonstrating something similar to the last code I wrote at Big Fish.)

Practicing with running WordPress in Docker today

So one of the things I want to do during my between-jobs downtime is practice my coding. And in particular, since I thought it’d be nice to a) start small and b) play with something I’m actually interested in coding (as opposed to, say, just focusing on random interview-type questions which will eventually bore me to tears), I decided I’d try to play with making a small WordPress plugin.

I’ve already done one that I’m running locally on Annathepiper.org: namely, to show y’all my archive of roleplay logs. Eventually I want to do a newer version of that, something that might let me actually practice setting up a simple web service.

For now though I’m going to do something less complicated. There’s a very old plugin called “lj-tag-parser”. This thing has a very simple job: allowing the LJ-style syntax for usernames and communities in your WordPress posts and comments. I’m using it right here on annathepiper.org, which is why you can actually see LJ-style usernames and tags if I write something like, say, userinfoannathepiper.

However, this thing hasn’t been updated in ages. And I thought it’d be nice to expand it to allow Dreamwidth-style syntax in addition to LJ-style, and possibly also allow generation of such tags via shortcodes.

But before I do all of that, I wanted to make sure I could set up a clean WordPress dev install.

In the past, when I’ve played around with dev-type WordPress stuff, I just did this on a separate blog on my annathepiper.org network. But coming at this with my SDET hat on, I thought it’d be cleaner and more appropriate to developing my coding experience if I set it up the way I’d do it in a work environment.

Which means a brand new, clean WordPress dev install. And in particular, using official WordPress and MySQL images from Docker.

For those of you who aren’t in the tech industry, suffice to say that Docker is a tool that lets you do exactly this kind of thing. You can set up a thing you want to play with in its own little container on your system, without having to worry about it interfering with anything else you might be doing. Docker lets you go about this in a few different ways. You can go get official images for things (like, say, the latest WordPress install) and do a single run using that image.

Or, if you want to do something a bit more complicated (like, say, running the official WordPress image AND a MySQL image that you’ll need to actually power the WordPress install), you can chain them together using a thing called Docker Compose.

Docker Compose works by you setting up all the config data you need in a file called docker-compose.yml. I’m still fairly new to the syntax this thing requires, but fortunately, I learned a bit about it while I was still at my previous day job at Big Fish. So I was able to utilize that knowledge to build a file that’d let me set up that clean WordPress dev install I want.

I did have to jump through a few hoops to get all the info I needed, though. Here are some pages that proved useful:

So now, as of this writing, I have a nice little set of Docker containers running on my dev box on Linux. And the nice thing about doing this via Docker, especially, is that I could take this exact same docker-compose.yml, reboot my box into Windows, and use it there too. All I need to be running locally is Docker and Docker Compose. The rest of it comes in with the images I specify!

And for the interested, I have checked in my final docker-compose.yml up on my personal Github account, and you can see it right here.