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

[boB Stepp]

On Fri, Apr 24, 2015 at 7:36 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> So many questions... let's hope I don't miss any... :-)
>
> On Fri, Apr 24, 2015 at 02:09:45PM -0500, boB Stepp wrote:
>
>> First question: What testing modules/frameworks should I start out
>> with? Doing a quick scan of the books I have, mention is made of
>> doctest and unittest modules in the Python standard libraries. But
>> mention is also made of two third party modules, nose and pytest.
>

[...]

> unittest is quite easy to use, and powerful. Some people complain that
> it is not very Pythonic, but I've never felt that. It is also based on a
> standard and much-copied Java library, so there are versions of unittest
> for many different languages. I quite like it.

I will definitely start out my learning by going this route. Will work
at work (Though Monday I must do an actual import of unittest to
ensure it is actually on both environments. Ya never know...) and also
at home.


>> And as to automated testing: I really, ..., really would like to
>> implement it on my side projects at work. But all such programs start
>> in a proprietary scripting environment, which can call external Python
>> (or other languages) scripts. The resulting final program is almost
>> always an unavoidable amount of propriety scripting language (Which I
>> always strive to minimize the amount of.), Solaris shell
>> commands/scripts and Python. As I have been learning more Python and
>> implementing it at work, I have found that the most successful
>> approach seems to be to first get all of the information I need out of
>> the CSA (commercial software environment) upfront, save it in temp
>> files, then call a Python script to start the heavy duty processing,
>> do everything possible in Python, generate a "reload" script file that
>> contains language the CSA understands, and finally run that inside the
>> CSA. How do I go about automating the testing of something like this?
>> And apply TDD write tests first principles?
>
> TDD principles apply to any programming language. So long as the
> language that you use to write the tests has ways of calling your shell
> scripts and CSA code, and seeing what results they get, you can test
> them.

CSA scripting can indeed call both its own scripts and external (to
the CSA) ones. But everything must start within the CSA, or none of
the CSA's scripts that are part of the overall program can be called.
As far as I know, there is no way to initiate a CSA script from the
outside, though just to double check I might post that question on the
CSA's Google group.

> However, I *religiously* write the documentation first. If I don't
> document what the function does, how will I know what the code should
> do or when I am finished?

Every day I code this sinks more deeply into my bones...

-- 
boB