Test and example workbooks

[mattpalermo]

It would be nice to make up a few "example/test" projects (they can be stored in a subdirectory of this repo). Each mini project can have a description instructing how CodeExport is used in that situation. This would serve two purposes:

1. It will serve as an example of the features of CodeExport and how to use it.
2. It will serve as documented test cases. At the moment when I want to test a build, the only projects I can test it on is CodeExport itself and a single closed source project I use it on. CodeExport in particular doesn't use all the features of itself so it is not a comprehensive test.

Some example/test projects may be constructed to show things that shouldn't work with CodeExport. A simple, clear warning in the test description will hopefully be enough to make sure that readers don't use those cases as examples of how to use CodeExport in their own project.

[spences10]

This is great, I'm the same for testing so this will be really handy

[spences10]

@mattpalermo are you able to give details/documentation on what you think should go in there?

Example:

Project1.xlsb

  Microsoft Excel Objects
    |-Sheet1 (TestSheet)
  Forms
    |-fromTestForm.frm
  Modules
    |-modTestModule.bas
  Class Modules
    |-clsTestClass.cls

Project2.xlsb

  Microsoft Excel Objects
    |-Sheet1 (TestSheet)
  Forms
    |-fromTestForm.frm
  Modules
    |-modTestModule.bas
  Class Modules
    |-clsTestClass.cls

What needs to go into them for the tests? and why does there need to be more than one?

[mattpalermo]

Thinking about the purpose of testing, we want to make sure that all the 'features' (or perhaps 'use cases') of CodeExport work as expected. An obvious way get started with this would be to create a 'comprehensive' project which uses as many 'features' as possible (e.g. forms, classes, modules, use basepath, use relative paths, use references).

For a more comprehensive integration test suite, we may want to have more than one test case that tests different use cases (e.g. not using the basepath property or using absolute file paths). We may also want to test that the program fails in the correct way in certain situations (e.g. just complete gibberish in the config file). However, there is a huge (perhaps infinite) number of possible test cases possible because of the combinatoric explosion of possible ways the program could be used, so we have to be smart about what is worth testing.

It would be nice to eventually also use unit testing so we can have more confidence about all those subtle edge cases.

I can get started on creating a 'comprehensive' test case using as many features as possible in the way that I think would be the common way to use code export. I am thinking that this would include:

• Simple form, class, modules, worksheet class and workbook class
• An empty sheet to make sure that it is not added to the configuration automatically.
• Paths specified relatively
• Use the basepath property
• Use the VBA project name property
• Use some reference(s)

For fun it might have some novel functionality...?

An accompanying 'readme' file will describe what is expected to happen when CodeExport is used on that project.

[spences10]

Closing this with reference to PR #72