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

[boB Stepp]

On Fri, Apr 24, 2015 at 5:03 PM, Alan Gauld <alan.gauld at btinternet.com> wrote:
> On 24/04/15 20:09, boB Stepp wrote:
>>

>> allowed to install anything else, strange as this may sound! Since the
>> only functional editors in these bare-bones Solaris 10 environments
>> are some simplistic default editor that I do not know the name of and
>> vi,
>
>
> vi is a great editor, no major problems there, except it
> doesn't have Python syntax awareness/coloring etc.

I am quite happy with vi! I did not mean to imply otherwise. However,
as you know I have only very recently started using Vim at home and
don't consider myself productive in it yet. My game plan, is once I
do, to start doing my editing at work directly in Solaris 10 on vi.

> However from memory doesn't Solaris 10 come with a CDE GUI?
> If so it should have a graphical editor in there someplace too.
> It was a reasonable coding editor in that it did block indenting,
> bracket matching, etc.

Your memory is indeed correct as to CDE. It has a default graphical
editor, the one I referred to as "simplistic", but if it has those
features I have missed them. When I say "default", it is this editor
that will pop up if I open a file for editing. I will look through the
menus and help again. Maybe I gave it short shrift too soon! That does
not mean that there is not another graphical editor in there
somewhere. I will poke around some more. But it seems, Alan, that
whenever I look for something that is *supposed* to be there, I find
basically a stub of an application that is missing required libraries,
etc. The installers of the planning software deliberately do NOT
install a substantial amount of what would normally be there in any
*normal* installation of Solaris. I once *begged* the support people
for this planning system to install the missing stuff for Emacs, but
they refused. Of course, this is after I found someone who even knew
what Emacs was, but that is another story...

But I may have to revisit all of this. We went to "Smart Enterprise"
on this software about a year ago. I managed to abscond with one of
the 810X boxes, with the planning software intact. I got my
administration to let me keep it as my development and testing
environment, since they do value the programs I generate (Whenever I
get time to work on them, which is usually rare.). I think now that as
long as I stay on this box, that no one will mind if I install
anything. I just need not to do so on our Smart Enterprise  clinical
planning environment. I actually started to explore this route about a
half-year or so ago, having figured out how to get the 810X connected
to the Internet, but then I got distracted since by what they really
pay me to do!

> And of course it has the original SCCS for source control.
> Which if there's only a few of you is adequate, and easy
> to work with. I used SCCS on several major projects over
> a 10 year period.

There is just lil ol' me. I will have to research SCCS.

>> And if successful automated testing can be done with this CSA
>> situation, how difficult is it to backtrack and add test suites to
>> stuff already written and being used?
>
>
> That's the traditional way of doing testing! Its not that hard
> if you can figure out a test environment. but from what I recall
> this CSA is a GUI? That makes injecting messages/commands much
> harder. There are tools that can do it but you can't install
> them...

It is a GUI. If I can initiate the testing process from within the CSA
with a small script in its language AND have the testing software
generate appropriate files in the CSA's language, then I can see how
it all would work. But it sounds like I would have to write (and test)
an interface program between the two. Of course I am just starting the
path to learning TDD, so that will probably be at least a little ways
off...

> In your case building a usable test environment may be the
> barrier, building the test is an evolutionary process that
> shouldn't be too hard.

I guess this is what I was thinking about just above...

> If you have a CLI interface then file redirection makes
> it relatively easy! If you can interact with its database
> then stored procedures might provide away in.

I do. But I don't see where you are going with this yet as I do not
know enough about how these testing enviroments, etc. work yet.


-- 
boB