Introduce Functions and Testing much earlier

[yarikoptic]

Describe the bug IMHO automated (unit-)testing of software is of great importance. That is why I was glad to see that at least a basic introduction to testing was added within "6. Functions" chapter of https://runestone.academy/runestone/static/thinkcspy/index.html (as compared to the original book which didn't have any testing covered). I think unit-testing is really logical to follow "functions" section since that is what can be unit-test-ed. Here, in fopp, testing chapter is delayed all the way until "18. Test Cases", whenever functions also delayed until "12. Functions". That is past many quite complex pieces of material/code students have to learn/develop without learning to accompany their code with unit-tests. IMHO very sub-optimal. I think that Functions and following them introduction to testing should be introduced relatively early as they are a fundamental feature of the language (and thus briefly presented in "2.4. Function Calls") allowing for modularity/reuse etc.

[presnick]

I'm glad you like the unit testing chapter. As written, it depends on the advanced functions chapter, but I don't think it depends on Exceptions or nested data and nested iteration, so you could introduce move it slightly earlier when teaching a course.

The decision to delay function definitions to later was a deliberate pedagogical choice. I have found that the basic control structures and data structures are much easier for students to understand, so the course gets off to a better start if you delay functions. Functions then make sense as a means of abstraction, to name chunks of code and make them reusable.

There are a lot of dependencies that have been mapped out, so it would be a non-trivial matter to reorder the function definitions chapter to put it back at the beginning of the book. If you really wanted to make a testing-centric book, with functions at the beginning, I think you could make a different book, reordering the existing material. But I think it would be a significant effort to do it well. Another option might be to just start with thinkcspy and add material from the unit testing chapter, perhaps breaking it up and rewriting it slightly.

By the way, I also had a version of the unit testing chapter that used the python unittest framework. I found that students struggled with it mightily, I think in part because its unusual use of sub-classing, with all instance creation happening behind the scenes, was hard for students to understand and maybe interfered with their understanding of classes and inheritance which they had just learned about. See https://github.com/presnick/ProgramsInformationPeople/tree/master/_sources/Testing

[yarikoptic]

Thank you @presnick for the detailed response! Ok, I will try to follow current FOPP order in my course and see how it goes. Re standard unittest -vs- ad-hoc test and getting back to "early testing". It seems that ATM the FOPP is completely avoiding the fundamental core Python concept which some might say in the core of testing frameworks and in all the test methods naming: assert:

runestone/fopp[ac101] $> git grep '[^.]assert'
_sources/Files/words5000.csv:3173,assert,v,10125,0.9
_sources/FrontBackMatter/fdl-1.3.rst:permission to use their names for publicity for or to assert or imply
_sources/SimplePythonData/VariableNamesandKeywords.rst:and      as       assert   break    class    continue
_sources/TestCases/Glossary.rst:        An assertion about the state of the program at particular point in its

and even AssertionError is just listed amond standard-exceptions and otherwise seems to be nowhere to find/encounter:

$> git grep Assert
_sources/Exceptions/standard-exceptions.rst:AssertionError               Raised in case of failure of the Assert statement.
_sources/Exceptions/standard-exceptions.rst:        +-- AssertionError

I guess if I (or someone) was to tune up FOPP to become more "tests driven", introduction of assert statement earlier in the book (could well be before functions this way) would prepare students a bit to the topic of test driven- or "assured" development ;-) And then (although probably wouldn't work nicely as current test. harnesses for displaying fail/pass) students could be introduced to the used in the real world py.test framework which uses those simple assert statements. Although py.test is somewhat of a monster, it is really easy to start with, and it would be very pragramtic -- I never saw test module being used ;-), rarely see plain use of built-in unittest (too much boiler plate, lack of extensions etc), and nosetests is dying off, py.test is taking over. I am not sure if it would be feasible to provide similar web eye candies having plain assert statements without requiring actual pytest somehow be present within skulpt, but thought to bounce idea first and either you may have considered such a flow in the past?

[presnick]

I have edited the testing chapter, to use assert and to refactor so that some sections can be introduced even before functions. I will be doing that in my course this fall and I'm optimistic that it will be helpful to students. Thanks for pushing in this direction.