[Tutor] Introductory questions on test-driven development and implementing Git version control.

[Laura Creighton]

In a message of Fri, 24 Apr 2015 20:24:38 -0500, boB Stepp writes:
>I have joined!

Great! Great!

>The Python versions at work are 2.4.4 and 2.6.4(?)(Not certain about
>the last digit there.) Based on responses to date, the fact that
>unittest is in the standard library and that because of this most of
>my books have something about unittest, I will probably start there. I
>imagine that everything I learn with unittest will transfer over to
>other testing frameworks.

What is even better, should you wake up one morning and decide that
you really want pytest, I written have a script that automatically converts
unittests to pytest tests.  It is included with the pytest distribution.

>> Are you absolutely certain that you cannot install git on your bare-bones
>> Solaris 10 environments?  Or plug in a memory stick and run code from
>> there?  Because it would make your life so much easier ...
>
>I think that I can get an exception here (See a post in response that
>I made earlier today.). What I am *certain* of, is that I cannot
>install anything on our clinical planning environment. The Solaris
>workstation that I now have all to myself--I'm thinking they will now
>let me do what I want with it. But I must double check... But anything
>I develop there *should* work in the clinical environment. The
>planning software is the same though that may change soon as there are
>plans to go up a version and they may not want to do that on my
>testing/development machine.

This thought 'if it works here, it ought to work there' is an unworthy
thought for somebody who has learned to test their code. ;)  You go to your
new machine.  You pull down your tests and your code.  You run all your
tests.  When they pass, you don't just _think_ that the code _ought to_
run here -- you _know_ the code will run because it passes all its tests.

This sort of peace of mind is better than money in the bank.

And, when they don't you are saved infinite amounts of embarassment.
The code  blows up _now_, when you are looking for problems, rather
than in the middle of showing off your code to some important, influential
person, because of tiny incompatibilities between what you have at home
and what you have in the field.  You can overcome, but never un-make a
bad first impression ...

So we have got to find you a way that works to get your tests and a way
to run them on your production machines.

Is there a way to stick a memory stick into these machines?  Can you
mount a filesystem there and cd to it?  Over at the university here, I
teach classes for the general public -- my buddies at the university
let me use their machines for free.  I am teaching children who don't
own a computer how to make games that run on their android cell phones --
or rather, we are all teaching each other, because I am very new to this
as well.  So they need a machine where they can do their development,
because developing on your cell phone is painful beyond belief.

Every Monday morning, and more often if they feel like it,
the university admins reset every computer to it's pristine 'just out
of the box' state.  (well, the password file will stay, but you get
the idea.) Any files you leave on the machine will be removed.  This
is to cut down on the rate of virus infection at the university, for
the most part.  So we keep all the code we care about on our memory
sticks, indeed in a virtualenv on our memory sticks.  Solaris has
virtualenv -- I checked -- see
http://www.opencsw.org/packages/CSWpy-virtualenv/

So, right now, aside from a mandate from on high that people who
plug memory sticks into their computers shall be boiled in oil, or
the situation where your machines don't have any external ports at all,
I cannot see why this solution wouldn't work for you.

See any problems with this idea I missed?

Laura