Here are my thoughts on software testing and development.
This is old news, but Github has open sourced Boxen the tool it uses inhouse for automated dev environment setup.
It uses Puppet for everything, and only supports OSX Mountain Lion and above (so it’s Mac-only).
I’ve been wanting to learn Puppet, so I’m going to check it out.
Anyone interested in learning Puppet might start here where you can download all the Puppet docs.
Another good place may be Graham Gilbert’s tutorials.
To make it easier to write provisioning scripts, I looked for a way to use the commandline to install Jenkins plugins. This is what is working for me:
Worked like a charm…you might have to restart Jenkins afterwards (
java -jar jenkins-cli.jar -s http://127.0.0.1:8080/ restart is one way…)
I’ve been working on a self contained Vagrant box for testing. Currently it loads, Appium, Jenkins, and rvm and some other things. It provisions from a base image and forwards the ports for Jenkins.
I still need to
- Find a way to have the box drive tests on simulators on the host machine. I’m going to see if the guest box can do this, even if the host box isn’t the machine with Appium. I want the Vagrant box to have as much on it as I can put on it, and I want to see if it can be where Appium resides.
- Modify the tests to use Appium remotely on the Vagrant box. I’ll want to fork a test repo I’ve been working on, modify it to work with the new setup
- Make jobs to kick off the tests.
- And maybe more! I’ll find out…
The prospect of doing this is very exciting to me. Setting all this up takes a lot of steps, so when done by hand, it may work on one machine and not on another. This should get closer to solving that.
Why you might want to do this
Even though automatic provisioning with Vagrant is great, because it allows you to take a download a publicly available base image that takes up gigs of space and custom configure it with a very small, easily shareable repo, sometimes it would be really nice to skip provisioning, because it can take a long time. Downloading and setting up things like databases or Java or things with tons of dependencies can take a long time, and you also need an internet connection to do the provisioning. Sometimes, it would be nice to just have something preconfigured, so you don’t have to wait for the install process to go through. Preconfigured boxes will be bigger, but sometimes that’s ok. You have a larger download up front but don’t have to wait for the setup. So if you have a complicated provisioning process that takes a long time, this is what you can do.
Use an existing environment
If you already have a box, just
vagrant up, and then
vagrant ssh into it.
Otherwise, for the sake of making this post self-contained:
1 2 3 4 5
Now you can install some random program. We’ll install Appium:
1 2 3 4 5 6
Finally, exit out of ssh with
CTRL-D and type
vagrant package. Vagrant will tell you where it puts the box. You can rename it, copy it, distribute it, and share it on a local network or on the internet.
Let’s say you start a new post in Octopress
Next time you generate and deploy the post will be published.
To change that, edit the file like so,
adding published: false to the YAML header:
1 2 3 4 5 6 7 8
When you’re previewing with
rake preview, you will still to see the drafts that aren’t published.
vim Improved (vi improved improved)/ vim Everywhere
I don’t think I need to get too much into why vim is great. You can read about what other people think all over the internet. I do want to recommend a few things for people that are already in love with vi keybindings, but maybe want vim closer to an IDE (without learning configuration stuff yet) or people that want to be able to use vi in fun places (like IntelliJ, RubyMine, or in the Ruby IRB REPL.)
Instant vim IDE: spf-13 is a GitHub hosted distribution of vim with add-ons and much preconfiguration. It has some nice documentation on GitHub, and it includes nice things like autocomplete (though I’d like to learn soon how to make it better, which I know you can do,) NERDTree for file traversing, CTRL-P for quickly accessing files, ZenCoding (now called emmet.io) for easy markup generation, TPope’s surround plugin, etc. Another great thing about it, is it already is set up with Vundle, so you can easily browse and install packages.
Alternative to Eclipse (with vim keybidings): Please anything but Eclipse! JetBrains has a much better IDE (my bias, again) called IntelliJ IDEA. Get the IdeaVIM plugin by going to Preferences > Plugins. You’ll want to change the shortcuts to go into and out of IdeaVIM mode, because they conflict with some shortcut for refactoring. I’m just using the Community version of it now (which is free,) but even though it is normally somewhat expensive, they randomly have fire sales (usually on holidays) where you can buy it for cheap. I’ve been using another, very similar, IDE by JetBrains just for Ruby, and it actually responds to mouse clicks, keystrokes, etc., in contrast to Eclipse (maybe I’ll learn to stop hating Eclipse someday. Please, somebody tell me how to enjoy using it).
vim in a Ruby REPL: Check out the interactive_editor gem. It’s very handy!
I’ve been writing tests with watir-webdriver, Ruby, and Cucumber for the past few months. Some tests have used the precursor to Cheezy’s pageobject gem,which is now deprecated, and though all the tests were still friendly to maintain, and eventually worked against Android and iOS simulators (via Appium), certain elements weren’t always accessible, and at times I wished we had something more compatible with the Java stack the company was using. Last night, I saw a presentation on GEB, and, though I must admit I was busy trying to set up and download some Groovy and Grails stuff at the same time to get ready for future hack sessions, GEB looked familiar and at times better.
GEB looks neat to me, here are some reasons why:
- Support for any major testdriver and mobile testdrivers, too (pretty much the same as watir-webdriver)
- Integrates well with a Java stack
- Page Objects (The demonstrator showed some great applications, including making an object for the dashboard on a webapp and manipulating it using GEB)
- Really good selectors. This is probably what really elevates this over watir-webdriver. There were some things watir-webdriver could not select easily, this looks much better.
Developer Environment Setups are Frequently Too Slow
I am hearing stories from other developers about how on many (most?) of their jobs, even if onboarding is relatively smooth, it is almost always the case that they have to wait too long for their development environments to be ready. In order to take care of these things, corporations sometimes need a few weeks to get employees up and running with these things:
- A computer with an installed OS on the network
- Access to shares needed for development
- All the software needed for development installed
- All services configured on the system
- Sudo access or administrator access
Just getting this simple stuff set up is taking too long. That’s a lot of money and time down the tubes.
I heard a lead tech on a project I was on recently suggest Vagrant as a tool for DevOps. Not knowing much about it, I asked him to explain, and it sounded great. Just now, with the project being over, and a week off before my next gig on Monday, I picked up a book on Vagrant, “Vagrant: Up and Running”, by Mitchell Hashimoto. I read it in a few hours (it’s a thin book.) It was awesome. Here’s what I learned: 1. Everything I wanted to automate as far as setup can be done. And there’s a name for this thing, when done robustly: provisioning. This includes:
- Setting up any OS, even OSX from an image. Vagrant handles this on virtual machines, which can be run on all the big virtualization platforms, and also from cloud service like Amazon EC2. Many prebuilt images (Vagrant calls them boxes) are available. As you would guess they are for free OSes. So, you can just make your own using VirtualBox if you want something like Windows or OSX
- Having a configuration that uses shell scripts to set up things automatically. You can also use Chef or Puppet if you want to use a server to control a mass install or take care of the infrastructure for a large organization. Chef and Puppet, are also specially made for provisioning, and as such, can generate reports on installs, help you by providing functions to make your installs more predictible (an example is a function that makes it easy to make scripts idempotent.)