Exercise 15: Reading Files: Learn Ruby The Hard Way: Practicum

So this time we are getting into something that has some meat to it. All of that ARGV and STDIN.gets had a specific purpose. Yes, being able to enter things from the command line are helpful. Interactively typing stuff in for a script is also kind of helpful. By far, though, the most beneficial thing that this offers is the ability to interact with external files; to open them, to read them, to change them, and to use them.


Since we are actually opening and editing files, we have the ability to do some, well, direct and deliberate things to the system, some of which could be dangerous if we are not careful (losing work in simplest case, erasing systems in the worst case). Thus, we need to be careful and pay attention to what we are doing.

We'll be working with two different files. One is our ruby script (ex15.rb) and the other is named ex15_sample.txt. This second file is just a plain text file that we will read into our ruby script.

Here are the contents of ex15_sample.txt file:

This is stuff I typed into a file.
It is really cool stuff.
Lots and lots of fun to have in here.


Yep, that's it.  A little anti-climactic, maybe, but it'll do :).

So our goal is to open the file in our script and print it out. We don't want to "hard code" the name of the file, though. We want to read it from the command line. That way we can read in other files later. ARGV and STDIN.gets let us dynamically add the file we want to use.

OK, there's a bunch of new things going on in here.

Line 4 is the first use of the File object where we use a new command File.open. File.open allows the user to, well, open a file.

Line 7 does something interesting and something we haven't done before. We are making an object of txt and calling the file.open option but using the txt label instead.

What You Should See


$ ruby ex15.rb ex15_sample.txt
Here's your file 'ex15_sample.txt':
This is stuff I typed into a file.
It is really cool stuff.
Lots and lots of fun to have in here.

Type the filename again:
> ex15_sample.txt
This is stuff I typed into a file.
It is really cool stuff.
Lots and lots of fun to have in here.

$

Extra Credit:

This is a big jump so be sure you do this extra credit as best you can before moving on.

Above each line write out in English what that line does.

If you are not sure ask someone for help or search online. Many times searching for "ruby THING" will find answers for what that THING does in Ruby. Try searching for "ruby file.open".

[here's a cool example: http://snippets.dzone.com/posts/show/5051]

I used the name "commands" here, but they are also called "functions" and "methods". Search around online to see what other people do to define these. Do not worry if they confuse you. It's normal for a programmer to confuse you with their vast extensive knowledge.

[ These come in different flavors depending on who is writing. I've seen functions, procedured, calls, objects, methods, etc. but I get the idea. The point is that we can create certain items and by adding a dot to them we can string commands and possible parameters based on what the parent command allows. The fact that they can also be named as variables or objects is both clarifying and confusing, but stepping back, it makes sense if you are doing something that involves many files or items. Naming them uniquely helps clarify which item is doing what.]

Get rid of the part from line 9-15 where you use STDIN.gets and try the script then.

Use only STDIN.gets and try the script that way. Think of why one way of getting the filename would be better than another.

[While being able to enter the value in the script would be a positive, you would have to be there to enter the name. by adding it on the command line, you can remove the human from the immediate process. this makes it possible to automate the procedure and put it into a script if desired, and it could be run 10,000 times without a person having to enter the file name. those same 10,000 script runs would have to have a human enter the filename each time]

Run ri File and scroll down until you see the read() command (method/function). See all the other ones you can use? Try some of the other commands.

[Well now, this is odd. Maybe it's a limitation to the PC version, but "ri File" only shows me the following:


C:\Users\Michael\LRtHW\Ex15>ri File
←[0m←[1;32mFile < Object←[m


(from gem activesupport-3.0.3)
------------------------------------------------------------------------------
←[1;32mClass methods:←[m


  atomic_write




------------------------------------------------------------------------------
Also found in:
  gem bundler-1.0.7
  gem thor-0.14.6


and that's it. On my Mac, I got "Nothing known about File".
]

Startup IRB again and use File.open from the prompt. Notice how you can open files and run read on them right there?

Have your script also do a close() on the txt and txt_again variables. It's important to close files when you are done with them.

TESTHEAD's TAKEAWAYS:

So we have made a big jump here. It may not seem like much, but we have now opened up our scripts to the ability of interacting with files, both to read from them and, later, to write to them (come on, you saw that coming, I'm sure ;) ). Having this ability means we can do things with our scripts that can be "hands off" from a human perspective. It also means that we can "pipeline" commands to our scripts via UNIX commands if we want to (granted, right now we're limited to filenames, but the whole point of having ARGV in the first place is to feed variables to the script from the command line, or other scripts). This is helping move us along to scripts that can prove to be very useful.

Moving Forward By Letting Go

Yesterday's post about how I spend my time actually came at an interesting juncture. As I'd said yesterday, to agree to do something, you have to be willing to not do something else. When Matt and I were sitting in the AST board meeting and the discussions about the Education SIG were happening, as I threw my hat in the ring to take on that responsibility, we both knew I'd have to free up bandwidth to do it.


Over the past fifteen months, I've edited 65 shows, plus several extra spots and other details that have helped to shape "This Week in Software Testing" into the format that it is today. By far the most time consuming aspect is the ongoing editing of the audio. Well, with next week's episode, I'm officially handing over a good chunk of the audio editing piece to Rick Baucom.


It's funny, this should be something that I should be totally happy to stop doing; it's not like I'm not going to be doing production for the show still (I'm going to be constructing the bumpers still and the final deliverable, at least for the foreseeable future, though it's possible I may pass that off too at some point). Still, part of me is resisting handing this off.


I think the reason is that, when we spend the time doing something, especially for a regular deliverable, we develop a lot of domain specific knowledge, and we just plain get good at doing it. When we feel we are good at doing something, we develop a bit of a pride in doing it. Anything that's truly onerous we should be happy to be rid of. In this case, while it was time consuming and meticulous stuff, I greatly enjoyed, and enjoy, doing it.


Having said that, I also know that I will have to, in due time, make commitments to focus on other areas, areas that will give me less time to do the day to day audio editing. I have help, and I'm grateful for it, but now I have to ask myself "am I willing to turn over the authority for doing something I've done for what seems like so long?" In all honestly, part of me isn't. What if the results are not the same as if I'd done them? Well, that's a risk... but so what? Do I have any belief that the podcast will suffer because of it. Well, it may. Or it may not. Fact is, I won't know until I let someone else try. They won't do things my way. They won't have my system down. They won't know the tricks I use to make things work the way that I do. And that's OK. They'll figure out their own ways of doing things. It may even (gasp!) change the flavor of the show, or they may discover some techniques or have access to gear that I don't, and that may even make the overall sound of the show even better, and frankly, that's cool, too.

The simple fact is, it's not my show. I don't own it. STP owns it, and from there, Matt owns it if any single person can say they do. I enjoy working on it, and I will stay connected to it as producer, but the daily engineering will go to someone else, and they'll make their own magic work. And it will be cool, it will be relevant, and it will be "the best software testing podcast... by some definition of best" :).

Here's to future days.

Exercise 14: Prompting And Passing: Learn Ruby The Hard Way: Practicum

So as I mentioned yesterday, I wasn't sure how to get gets.chomp() and ARGV to play together. When in doubt, check ahead and you might find an answer. Well, that's what I did and I found out something cool.

This example shows ways to isolate and focus on individual variables, as well as how to get gets.chomp() to play nice within a script that uses ARGV.

This script also prints a simple prompt to use in the script. The example is similar to a text based game (Zork or Adventure, anyone :)?). Also, I'm starting to get some strange issues with publishing my blog entries now because of the Ruby code interfering with Blogger's interface, so I'm going to copy the actual code details into image form (lets see if that resolves it).

OK, first thing (notice this from yesterday?), here's a change-up. gets.chomp() is represented as STDIN.gets.chomp(). Why? Because ARGV is being used. the default gets method will look in ARGV and try to read from the first variable. getting input straight from the keyboard (user input) is referred to in computer parlance as STDIN. So to read the users input, when ARGV is used, STDIN.gets is used. Cool, huh :)?

[here's what I wrote]

What You Should See

When you run this, remember that you have to give the script your name for the ARGV arguments.

[and here's what I get]

Extra Credit

Find out what Zork and Adventure were. Try to find a copy and play it.

[
Zork: http://pot.home.xs4all.nl/infocom/zork1.html
Adventure: http://www.wesleyholland.com/misc/adventure/adventure.html
]

Change the prompt variable to something else entirely.

[ prompt = "#{$0} >> " . Note this is performing string interpolation in the prompt. I don't k now why I'm mentioning it, I just think saying "string interpolation" is fun, really :) ]

Add another argument and use it in your script.

[Since I'm not sure how to enumerate the ARGV vartiable beyond the ARGV.first option given as an example, I've played coy and figured that if an array begins, it has to end, so I entered ARGV.last as an option (note, it's coincidence that  firstname corresponds to first and lastname corresponds to last, but that's not what they represent. They represent the first argument in the array and the final argument in the array]

[I get that string interpolation can take place with this example and within this format of multi-line printing, and that's pretty cool :) ].


TESTHEAD's TAKEAWAYS:

Wow, I haven't see or heard about a text based adventure game since I was a kid in the late 70s or early 80s. That brings back memories. It also reminds me how cool the programming behind some simple question and answers could totaly suck you in. It was neat to see a reminder to how this was done, as well as to experiment with pulling in variables from the command line and within a script.

Fitting It All In?

I received a great note today from someone that complimented me on the blog and said they found encouragement from what I wrote. They also had a question that I think deserves to be answered (hence today's post)...


"One thing that fascinates me is how you manage to pack so much into your day and if it was not too much of an imposition, I would love to see you write up an account of how you manage your time, between all your endeavours and also as an active family man."


First, I think it's important to realize a few things up front. I may give this image of being hyper-productive, and some days I am, and other days, well, not so much. I value my sleep, I value my time with my kids, and I also like doing things and often need to do things that get pushed to the back burner. Whenever someone says "wow, you get so much done", I often laugh and say "have a look at my front and back yard sometime" ;). Seriously, though, this does point to a fact of life that I'm totally stealing from Merlin Mann and a talk he did a couple of years ago about "Time and Attention". The simple takeaway from Merlin's talk is that "we need to put in time to do great STUFF. We need to put in attention to do GREAT stuff". Time is the easier value to manipulate. Attention is the more difficult one.


A simple truth and one I struggle with a lot is that I can't do it all. I can't even get vaguely close to doing it all. It does help, though, to get a handle on the things that you are doing and understand why you are doing them. that way, If you really want to see where there's some give and take in your day, you can honestly and directly evaluate what you want to change and why. I've mentioned in the past that I use a software program called "Rescue Time". We had a heated exchange in a Weekend Testing session about it and the idea that it's evil incarnate for organizations to use stuff like this to track their workers. I do, however, find it to be interesting on a purely personal level in that it gives me a snapshot of the things that I actually do (at least online) that show me where my attention actually goes. Oftentimes, we learn some painful truths about ourselves this way. We think we are hyper focused and that we are producing a lot, when the data tells us otherwise (and I'll leave it to the individual to decide it it's worth their time to do this for themselves. I personally find it helpful).


Another thing I do is, well, this blog. Two things to be aware of. First, many of these entries are written in advance (not all of them, but a lot of them are, and sometimes I have several finished and waiting in a queue). When you see a post that is marked as published at 5:00 AM or 5:00 PM, that's a clue that that was likely a scheduled post and written in advance. I also often have dozens of blog posts in various draft forms. Some are outlines, some are a couple of sentences, some are several paragraphs. As I wrote in my book review for Gerald Weinberg's "Weinberg on Writing: The Fieldstone Method", I've been doing this for years but never really knew there was a term for it. I often keep a text editor open on my desktop and during the day, if something pops into my head, I'll write down a though, sometimes a paragraph or two, and it may sit for days or even weeks. I do make it a point to go through them each day and see what I can do with them. It helps me to focus my thoughts and it gives me scraps to work with at various times. Also, my blog is, for me, the repository of my learning. It is the home of all my doubts, my fears, my goals, and it's my best line of defense against "The Resistance". Once it makes its way into my blog, it's do or die time. The Resistance doesn't stand a chance :).


I've also commuted via train the past several years, and whenever I'm on the train, I'm doing something related to "my hobby of furthering my testing knowledge". It's a 25 minute ride up and back, plus the wait time for the train to leave on the way home (I take CalTrain and 4th and Townsend is the start/end of the line). So there's 50 minutes of dedicated time should I choose to use it with little interference of any kind. Often, the favorite use of this time is editing audio for the TWiST podcasts.


Finally, my one "great trick" (and when I tell people about it, they often think I am nuts) is that I have a special block of time I call on maybe once or twice a week. If I really have something I want to focus dedicated and uninterrupted time on, I do it then. When? Early in the morning. How early? 3:00AM. What?! Why?!! I've not quite figured this one out, to tell the truth, but for me personally, my brain is literally "on fire" between the hours of 3:00 AM and 7:00 AM. It is the best time for me to do anything that requires tremendous focus. I can do stuff at other times during the day, too, but there's something about that four hour block that is really amazing. It's also exhausting, so I don't call on it all the time, but when I need to make headway on something important, or I need to devote all my cycles to something that's been driving me crazy, or really needs to get done, I'll set up my "early office hours" as an appointment, get to bed a little earlier the night before, and hold an early morning session to focus intently on whatever problem or project I'm struggling with. Also, it's very easy to get a lot done when everyone else is asleep :).


In the end, though, there are times when I just bag it all and head out with my family and friends, hang around the house, go watch a marathon of Bones or Psych or "fill in the blank". Sadly, some things have taken a significant back burner. It's been almost two years since I've played meaningfully with a video game (I have a few that I want to play, but not bad enough to break my current momentum). I listen to a lot less music than I used to. I do a lot less "for pleasure" reading. And frankly, I'm sure a lot of the things that I do I could do a whole lot better were I to jettison something else from my life. The simple fact is, when you agree to do something, you are agreeing to not do something else.


I down-shifted my life for a number of years specifically so that I could be a hands-on dad with my kids when they were younger. Now, I'm shifting back into a higher gear with my own career pursuits and putting in the energy necessary. This is something I've discussed with my wife and kids and they understand the reason why I am doing things the way that I do them. They are also there to let me know when the balance is too far out of whack and when I need to pull back and focus on other things. In short, there's no great magical "do this and you can get a lot of stuff done". It's really all about grabbing the opportunities when they present themselves, and knowing when you are stretching yourself too far or spreading yourself too thin. Sometimes, I'm good at this, other times I'm not. I can say it does help to enjoy what you are doing. It's a lot easier to get a lot of stuff done when you are having fun doing it :).

Exercise 13: Parameters, Unpacking, Variables: Learn Ruby the Hard Way: Practicum

So far we have been including everything either in the script, getting information from the keyboard as an internal prompt (gets), or pulling in functionality from another file (require). These work well for basic interaction and are OK if we want to just call a script name and run it. It doesn't give us much flexibility, though, as to how much information we can provide up front (actually, it gives us no flexibility).


Most command line programs we run have the ability to be "fed" other input items right along with the name of the script or command (think of "grep text example" to pull out the word 'text' from the file 'example'). grep is a command. text and example are arguments to that command. This next example shows how to feed arguments to a Ruby script.


first, second, third = ARGV

puts "The script is called: #{$0}"
puts "Your first variable is: #{first}"
puts "Your second variable is: #{second}"
puts "Your third variable is: #{third}"


Before we get started, some cool stuff is happening here. ARGV is a special kind of variable (a CONSTANT, meaning we don't want to tweak it once we assign something to it. CONSTANT's are easy to spot. They are in ALL CAPS). ARGV means "argument variable". as it's name suggest, and values entered in on the command line will be stored in this value.


What we see happening in the first line is that ARGV will hold whatever we type in at the command line. It doesn't care how many items we provide (items being anything we type with a space between them, see my examples in the command prompt window below). In the first line, we also define three variables that will get the first three values that are typed in after the name of the script (if we type in no values, then the variables will be assigned NULL). Also, anything I type above and beyond the three defined variables don't get assigned anywhere but ARGV. This idea of taking variables and assigning them directly from the command line and from ARGV is what Zed calls "unpacking". I think it's a useful metaphor, it makes sense, and it shows that ARGV also still has all of the variable values it received.


The name of the script also has a variable value. It's called '$0'

[so here's my version]

[and here's its output]

What You Should See

Run the program like this:

ruby ex13.rb first 2nd 3rd
This is what you should see when you do a few different runs with different arguments:

$ ruby ex13.rb first 2nd 3rd
The script is called: ex13.rb
Your first variable is: first
Your second variable is: 2nd
Your third variable is: 3rd

$ ruby ex13.rb cheese apples bread
The script is called: ex13.rb
Your first variable is: cheese
Your second variable is: apples
Your third variable is: bread

$ ruby ex13.rb Zed A. Shaw
The script is called: ex13.rb
Your first variable is: Zed
Your second variable is: A.
Your third variable is: Shaw


Extra Credit

Try giving fewer than three arguments to your script. What values are used for the missing arguments?

[As demonstrated in my initial run, if you don't provide arguments, null avalues are assigned and the variables will print out as blank. If you assign two values, the first two will appear, the third will be blank. If you assign five values, the first three will appear and the fourth and fifth values will be ignored (they haven't been unpacked, they still in the ARGV warehouse]

Write a script that has fewer arguments and one that has more. Make sure you give the unpacked variables good names.

[see below]

Combine gets.chomp() with ARGV to make a script that gets more input from a user.

[so here was my first attempt]

[and here's what I got]

Hey wait a sec... why is it doing that?! Hmmm... I'm guessing we can't use a regular gets in this case because of the arguments on the command line. So I'm going to do something shameful... I'm going to peak ahead... and hey, this looks like it might work.

[second attempt]

[second output]

OK, that looks doable (yeah, we'll be getting into what that STDIN means tomorrow :) ).

TESTHEAD's TAKEAWAYS:

By using the ARGV constant, and having the ability to unpack values into other variables, we can provide a lot of flexibility to our programs. This flexibility can help us pull values from many places (from the command line and from the user input to a program). Pulling from the command line allows us to set up things like "flags" and make other conditional options... but I'm getting ahead of myself. Suffice it to say, you are no longer limited to just your script for input.

Questions You Wished You Had Asked

There is a discussion going on over on the LinkedIn group for the Software Testing Club, and I decided to participate in it. The topic?

"What questions were you afraid to ask when you started your career in software testing?"

 I had a pat answer because of something that was happening at the time, and it was the first thing I thought of, but after I responded, I realized there were more questions I wished I'd asked back in those early days.


As many of you know, and as I have mentioned, my route to testing came in an indirect way. I didn't plan to be a tester, and in many ways, I don't think many people actually do plan to be testers. It's a career that tends to pick them, I think. Still, when I started, there were a lot of questions that, for various reasons, I really didn't ask, in part because I didn't want to tip off how ignorant I was (and looking back now, was totally stupid of me, because we are frequently ignorant of issues in any product, and the only way to learn is to ask). So if I were to talk with a new tester, someone who wanted to understand what was going on, and wanted to be a better tester, here's a list of questions I'd encourage them to ask (and always ask, frankly):

• Why am I here?
• What value to the development process do I provide?
• How can I best serve the development team (and please do not interpret that as "how can I not rock the boat and just keep everything mellow")?
• Is there really a value to a voluminous test plan?
• Does anyone actually read these (voluminous test plans)?
• Why do we spend so much time documenting what we are going to do and almost no time actually doing it?
• Is there a better way to do this?
• Who is our customer?
• Will what we are making help them, or hinder them?
• Have I really thought of everything that I can consider to effectively examine this [fill in the blank]?
• What's my story?

Am I missing a bunch of possible questions in there? Yes, I am. I could come up with a huge list of "automation vs. manual" or "scripted vs. exploratory" or "waterfall vs. Agile", but ultimately, I think the above questions would be great for any tester to ask. Ask them at the beginning of your career. Ask them after several years experience. Ask them when you are a senior player. Ask them when you manage others. Ultimately, though, I think all of these questions can best be summed up in the start of a question. Two words. Words that I think Ajay Balamurugadas has encapsulated well in his e-book, and that you might appreciate and should consider more often, too.


That question?


"What if...?" 

See where that one leads you ;).

Exercise 12: Libraries: Learn Ruby The Hard Way: Practicum

Anyone who has spent any time around Ruby has heard about gems and other files that can be called into your ruby scripts. There's a variety of names for this, and the one that's most common and understood by most developers and even casual programmers are "libraries". A library is a collection or readily written items that we can call on and "the wiring under the board" has already been done for us.


Below is some example code that is being pulled in from a library. Note also that it uses some actual block structure (see the do and the end and the indentation of code. this is the first code we've seen formatted like this, which leads me to believe we'll be seeing more stuff like it shortly).


So let's take a look at this:


require 'open-uri'

open("http://www.ruby-lang.org/en") do |f|
  f.each_line {|line| p line}
  puts f.base_uri         #
  puts f.content_type     # "text/html"
  puts f.charset          # "iso-8859-1"
  puts f.content_encoding # []
  puts f.last_modified    # Thu Dec 05 02:45:02 UTC 2002
end

[Here's what I have written]

[and here's what it does... and what it does is looks to take every line of ruby-lang.org and print it out in the format described]

So the first line uses a command "require". What is it? What makes it special? And why should I be requiring it in the first place? The simple answer is that, instead of reinventing the wheel lots of code has already been written for us to call, to use, and to reference when we write our own code. Zed calls these "features" and that's fine, but most anyone who's had any involvement with a programming language recognizes a library when they see one :).


Extra Credit


Research the difference between require and include. How are they different?


[Hmmm... now this is interesting. From what I've read, it would seem like the include I used to use with C and require are very similar, in that for that given ruby file, the require command is sysnonymous with how other languages use "include", meaning bring thee features or functions into this file and reference them as though they were in the file directly. Ruby's include seems to be like other languanges "includes" only much more so, like at the direct language level. I'm not sure I get what that means, but it's enough to know that require will be what I'll more than likely use in projects and at the file level.]


Can you require a script that doesn't contain a library specifically?


[To tell the truth, I don't know at this stage. I would guess that, like any other language, we'd need to have some kind of function or module defined to need it to be included/required. Based on my experience at this stage, I honestly don't know, but I'd say "probably not".]


Figure out which directories on your system Ruby will look in to find the libraries you require.


[On my PC, it's in C:\Ruby192\lib\ruby\1.9.1\ ]


TESTHEAD's TAKEAWAYS


OK, that's kind of interesting, and a bit unexpected. I've seen the require, and I figured it worked like include. I'm not sure I get why the different nomenclature; it seems to me if include is such a de-facto standard in languages, why change it in Ruby? Note, I don't have the answer for that, it's a question I have right now.

An Automation Mea-Culpa

For the last several months I have been working on trying to get together a fully customer facing web automation framework. Yes, this is the classic "all up front, what the customer sees" automation project, the holy grail of effective web interaction testing. And it's a bit aggravating at times, if I may be frank!

I'm saying this to be totally honest. There are so many moving parts to be aware of, so many little things that have to be considered, and even though I think that the Cucumber/Rspec/Ruby approach is actually pretty good for an overall framework, it still leaves a lot to be desired from a consistency and reliability standpoint (and yes, I'm totally willing to believe that it's my growing understanding of how Cucumber, RSpec, Capybara and Ruby all fit together that's at the heart of this). Still that's not the point of today's post. Actually, it's to give a little bit of empathy for our development brethren who have to maintain things that quickly become anything but simple.


A little background; the scripts that I write are not terribly complex, and at the moment, I've only had to research a handful of Rspec and Ruby statements to drive and work with Capybara and WebDriver beyond what was directly provided for me (quite a lot of functionality is just straight capybara calls with little in the way of modification necessary... kinda' nice, actually). Still, there's a fair amount of stuff that has to be configured to play well with others, as my tests have to work correctly and reliably on four different environments. We do frequent pushes from development machines to a demo machine, and then to a staging machine, and finally if all looks clean we push to production. This is a common format in many organizations, and my goal is to maintain just one set of test scripts and have them run effectively on all four environments. While the scripts themselves are the same, keeping four different environments in sync can be a challenge, and the last few days, I've been doing a fair amount of refactoring. One of the refactoring changes I made moved login credentials to a single file.

I thought I knew where all of these environments variables were and that the config was straightforward for the machines, but I was wrong. Because of that, when I thought I was using a test account for various tests, on one machine, the accounts were linked to each other... meaning my test account was also sending updates to my personal twitter account (fine earlier in the testing process, but unacceptable in this late stage). My thanks to a fellow tester who alerted me to the fact, and I sheepishly had to apologize because he had to alert me twice! The second time through, I scrubbed every line of every file, and found the error (and modified the script to make sure the same mistake didn't happen again).


Sometimes as testers we can get a little self righteous and bag on developers when they make bone-headed mistakes. Believe me, I've gloried in that same pastime, but today I'm seeing just how easy it is to think you've fixed something only to see that, in truth, you only fixed one symptom of a deeper problem. We testers like to believe that, were we in the developers shoes, surely we wouldn't make the same foolish mistakes. Well, guess what? Yes, yes we do, and they are just as embarrassing. Maybe even more so, because now I have no one else to blame. These are my scripts, my underlying code, my configuration files, my clever little clean-ups that, in hind sight, some don't look so clever after all. And this time it's my turn to play fix, test and try again... same as it ever was.

I still feel testing requires a diligent effort and a solid focus, but really, I'm starting to develop a bit of empathy for my developer cousins. Shipping is actually harder than it looks.

Exercise 11: Asking Questions: Learn Ruby The Hard Way: Practicum

So far we've been doing a lot of printing, and that's been a one way street. Programs aren't terribly interesting that way, they need to have input to typically do anything useful. In these early stages, that means we will be looking at physically feeding input from a prompt (later I'm sure we'll deal with file input or other means of geting input into the program).






So let's feed some input to the program, shall we?

print "How old are you? "
age = gets.chomp()
print "How tall are you? "
height = gets.chomp()
print "How much do you weigh? "
weight = gets.chomp()

puts "So, you're #{age} old, #{height} tall and #{weight} heavy."

[and here it is]

In this case we use "print" instead of "puts". print doesn't add a new line automatically, so the answer to the question appears on the same line. puts  automatically adds a new line.

What You Should See

$ ruby ex11.rb
How old are you? 35
How tall are you? 6'2"
How much do you weigh?  180lbs
So, you're '35' old, '6'2"' tall and '180lbs' heavy.
$

[Well, I'm a little older and weigh a little more than Zed does, but other than that, yep :) ]

Extra Credit

Go online and find out what Rubys gets and chomp methods do.

[gets allows the user to enter a string value directly to input. chomp removes the newline from the end of the line. gets.chomp() means that whatever is entered stores that variable name only, not the newline. Also, chomp can be applied to any variable, see below]

Can you find other ways to use gets.chomp? Try some of the samples you find.

[see below]

Write another "form" like this to ask some other questions.

TESTHEAD's TAKEAWAYS

We'll be dealing with this stuff in a little while, but gets is an object and chomp is an object method. Notice that we used chomp both with gets, as in gets.chomp, but we also used it with an other variable, which is "name". We assigned name with a value by using gets, and then modified name by using name.chomp, or put more simply, name without the newline at the end.

Monday Grab Bag: Guest Post, Weekend Testing and Test Design

I received an invitation to do a guest blog post for my friend Devon Smith-Tooley. Devon writes the terrific blog "Everyday QA" and if you are not familiar with it, well, I recommend you get familiar :). My blog post is titled "Who Do You Want To Be Today?" (yes, it's a play on words of an old Oingo Boingo song, just in case anyone out there might wonder ;) ), and it is specifically about me adapting my role as a Sapient, Exploratory Tester and developing the chops necessary to be more development focused (sort of a Software Development Engineer in Test, but not quite. More of a 50/50 split). In any event, please check it out, and if Devon isn't a regular read for you, I recommend adding her to your blog list.


Second, we had an interesting Weekend Testing Americas session this past Saturday. My thanks to Albert Gareev for stepping up and facilitating (again, his second time :) ) so that:

a. I could actually test
and
b. know that we are developing some depth in thje facilitator department.

By having more facilitators, we can offer more sessions and not be dependent on one person's schedule for sessions to occur. Anyway, this session was dedicated to getting a primer in Penetration Testing, and using a tool that allowed for some interesting manipulation of sites. The tool in question is called Groundspeed, and it allows users to make modifications to form fields and other properties on a web form, including hidden fields. We didn't go into depth as to how to do malicious things, but we did see how we could actively and in an Exploratory fashion find ways to change the behavior of the site. Albert posted a great writeup and discussion on his blog. If you'd like to follow along with the session, the experience report is here.


Finally, the pilot of the AST BBST Test Design course officially started yesterday, and therefore a vast majority of my copious free time (he says sarcastically) will be dominated by atively reviewing the content, checking the questions and seeing how well I actually understand the material, while I am helping teach the course (thankfully, Cem is taking the lead on this one, as I'd be *way* out of my league on this without him). This is a survey course, which means that we are basically drinking from a fire hose. It will provide a lot of material, and something in the order of 500 references. The slides for this course are more than Foundations and Bug Advocacy combined. The information is apread out a bit more, too, so that shouldn't sound as daunting (but it's still a lot of material). I'm also working through the course on the side and a bit ahead of the other participants in the hope of catching any issues or areas that might be problematic or vague (plus this way I can say I took the course along with everyone else :) ). Count on the fact that I'll be blogging about interesting aspects about this new class (and I expect there will be a *lot* of them).