Notes from an intuitive programmer: testing

Showing posts with label testing. Show all posts

Tuesday, September 23, 2014

Visual project design & reporting & Pivotal Tracker with add-ons

Friday, March 22, 2013

StackExchange family (including Stackoverflow) doesn't care about signout

I again registered a test account for 'Log in with Stack Exchange'.

Disappointingly, after logging out of every (SE family) site, it still lets me log in again merely by button clicks, while I type nothing.

After more than a year, clearly the managers of the Stack Exchange network family of websites don't give a hoot about protecting users of shared computers with a truly effective signout.

What if some rude person at a party click-logged into and deleted someone's account, thus trashing their vast accumulation of reputation?

Copyright (c) 2013 Mark D. Blackwell.

Friday, November 2, 2012

PC timer for online tests, howto

I needed a timer to take online tests with (on an IBM PC).

And I found PC Timer. It seems ideal for this purpose:

http://www.brothersoft.com/the-pc-timer-1862.html

In order to alert me when a timed test is nearly over, I configured it to run this simple batch file:

@echo off
mode con: cols=100 lines=8
color 4e
echo .
echo .
echo "Time's up"
echo .
echo .
pause

Simple!

Presumably, it will be useful in timing other things, as well.

Beyond the timer, it also has two alarms (for moments, rather than durations, as of version 4.0).

Copyright (c) 2012 Mark D. Blackwell.

Monday, September 17, 2012

Website page layouts, proofs of concept

A big part of frontend website development is implementing webpage layouts using CSS stylesheets (of course).

Recently, I've been experiencing a great deal more of business in the area of layouts (specifically for Rails websites) and especially the work of implementing these layouts through developing CSS stylesheets—whether or not this is really programming! (Well, I think it is.)

I find it much less efficient to run the Rails server, and much more efficient to 'web-browse' the local filesystem. The work progresses much more quickly, in other words, when it is isolated from any complicating factors arising from our misunderstanding of the Rails server, jQuery, ERB/HAML, and perhaps even Sass. The weightiest reason for this improvement (by far) is the troubleshooting principle: 'divide and conquer'. Less important is that the filesystem also is relatively quicker.

It is much more doable (dare I say, even feasible) to get isolated layouts working using pure CSS and HTML (while keeping class names simple). And the same is true while paring down a stylesheet to be as simple and clean as possible.

Of course, further simplifying cross-browser development is the use of a CSS-reset stylesheet. Also it is essential, for HTML5's semantic tags: header, footer and nav (etc.), to include a (JavaScript) HTML5 shim (or 'shiv') script. So I include both of these best practices.

I have prepared a repository of my CSS (layout) proofs of concept on GitHub—including nine(!) useful proofs (as of now, September, 2012).

These layout proofs contain stylesheet code the way I write for Rails projects as much as possible (without actually including Rails).

Copyright (c) 2012 Mark D. Blackwell.

Saturday, August 11, 2012

Simple webserver for troubleshooting, howto

Here is an extremely simple web server to use in troubleshooting your code, derived from Yohanes Santoso's wonderful Gnome's Guide to WEBrick.

It serves any directory tree you're working on (including HTML properly) without any complexity arising from Rails, Sinatra, or any other web frameworks. (Isolation is a good thing when troubleshooting.)

Just place this in your tools directory (e.g., ~/t/serve-files — making sure it's executable):

#!/usr/bin/env ruby
require 'webrick'

program_name = $0
puts "#{program_name} #{ARGV.join ' '}"

puts "Running Ruby #{RUBY_VERSION}"

include WEBrick

options = {
:BindAddress => '0.0.0.0',
:Port => 3000,
:DocumentRoot => Dir.pwd,
}
server = WEBrick::HTTPServer.new options

%w[INT TERM].each{|e| trap(e){server.shutdown}}

server.start

Copyright (c) 2012 Mark D. Blackwell.

Monday, August 8, 2011

CSS selector objects and methods for testing in Ruby

Let's say, for a given web page, you are writing some tests. And, supposing, you want to test whether the page contains a single DIV, of CSS class, 'only'.

And, you want to know whether the DIV (or the page) contains a single FORM, of CSS class, 'good-form'.

And further, you want to know whether the FORM (or the page) contains (among other things) a single INPUT, of CSS class, 'my-input'.

And further, whether that INPUT has CSS attribute, 'type=text'.

So, a CSS selector, useful for finding that on a web page, would be:

div.only > form.good-form > input.my-input [type=text]

Right?

Maybe (in your test) specifying descendents instead of children would have a better flexibility, allowing later intervening DIV's (for instance). With this difference, the new CSS selector would be:

div.only form.good-form input.my-input [type=text]

How might one like to specify these selectors, speculatively and ideally? Even better than the CSS selector strings in Ruby above might be... what?

(A.) HTML elements

Well, it might be nice if code for DIV's could work simply like this:

D.class 'only'

(Unfortunately, this would clobber Object#class, probably interfering with essential Ruby functionality elsewhere in our application.) We could compromise and give it a longer method name:

D.css_class 'only'

(B.) HTML Attributes

A web page might also, in addition to an INPUT element carrying all of the desired attributes, supply some other INPUT with fewer of them, or indeed another kind of INPUT entirely.

So, obviously, it is good to test for:

o The desired number of INPUT's (in total), and
o The presence of each INPUT, carrying all the attributes desired.

In light of this, wouldn't it be nice if one easy method invocation could assert the unique presence of exactly one INPUT, plus its unique presence carrying a specific set of attributes?

Another thing possibly useful might be checking the attributes one at a time; I don't know.

The same would probably apply also to any other kind of HTML element having attributes.

A seemingly good way to invoke the method would be:

attribute 'type', 'text', 'value', 'your name here'

And, for unpaired attributes:

attribute 'hidden'

So: how could these semantics really work? Here's an example, carrying the idea further:

(C.) An implementation

# Fuller Example of Web Page Testing, Using CSS Selector Objects and Methods:

module CssSelectorConstants; D,F,I = %w[ div form input ].map{|e| CssString e} end

class SomeTestClass

extend CssSelectorConstants

def test_web_page
d_o = D. css_class 'only'
fg = d_o.descend(F).css_class 'good-form'
im = fg. descend(I).css_class 'my-input'

a_t = im.attribute 'type', 'text'
atv = im.attribute 'type', 'text', 'value', 'your name here'
av = im.attribute 'value', 'your name here'

# There should be exactly one DIV, 'div.only':
assert_select d_o, 1 do

# And within that, exactly one FORM, 'form.good-form':
assert_select fg, 1 do
# I.e., exactly one:
# div.only form.good-form

# And within that, exactly one INPUT, 'input.my-input':
assert_select im, 1
# I.e., exactly one:
# div.only form.good-form input.my-input

# And exactly one INPUT, 'input.my-input[type=text]':
assert_select a_t, 1
# I.e., exactly one:
# div.only form.good-form input.my-input
# [type=text]

# And exactly one INPUT, 'input.my-input[value=your name here]':
assert_select av, 1
# I.e., exactly one:
# div.only form.good-form input.my-input
# [value=your name here]

# And exactly one INPUT, 'input.my-input[type=text,value=your name here]':
assert_select atv, 1
# I.e., exactly one:
# div.only form.good-form input.my-input
# [type=text,value=your name here]
end #form
end #div
end #def
end #class

See also:
CSS selector objects & methods (for Rails; GitHub)

Copyright (c) 2011 Mark D. Blackwell.