[ALOY-1115] CLI command to create a project from an Alloy test case

Description

Comments

1. Tim Poulsen 2014-09-16 PR https://github.com/appcelerator/alloy/pull/565 Functional test: 1. Create a new Titanium Classic project ti create --name foo 2. Change to the project's directory cd foo 3. "Alloy-ize" the project, specifying the test app to import by adding the --testapp parameter followed by the directory and name of the test app to import. E.g. alloy new . --testapp ui/tableview 4. Build the project for fun & profit ti build -p ios When testing, be sure to test on OS X and Windows (should work on Linux too). Make sure to do test builds for iOS, Android, and MobileWeb. On Windows, you should use the \ slash alloy new . --testapp ui\tableview though in theory the / should work too. Notes: * None of the samples that require files outside of the app folder will work without additional steps. For example, you would need to create an i18n folder for the advanced/localization app. Or, you would need to install the native modules used by the advanced/native_modules app. * The "testing" apps (those used internally by Alloy developers) are not installed with the rest of Alloy. So, you cannot create a test app based on any of them.
2. Tim Statler 2014-09-18 This is awesome, Tim. My comments: * The workaround for this is [already documented](http://docs.appcelerator.com/titanium/latest/#!/guide/Alloy_Samples-section-37535160_AlloySamples-TestCaseExamples), but if the test app contains a specs folder you usually get runtime errors. Maybe the tool could alert the user to this if the target sample has a specs folder...maybe mention the same workaround? Might be asking too much, I realize. * This is purely a personal preference (so take with grain of salt) but I'd prefer a command line option to the testapp: prefix, e.g. alloy new --testapp ui/tableview. But I'm fine with the current approach.
3. Tim Poulsen 2014-09-18 Thanks for the feedback. I should be able to filter out copying the specs folder so that it wouldn't be a problem for users. I initially tried with a --testapp arg but it wasn't working and the prefix was easier for a proof of concept. But I'll see about reworking it to use the argument.
4. Tim Poulsen 2014-09-19 PR updated to implement --testapp arg rather than prefix method originally used. Also copying excludes the specs folder. Added a test to the jake test:spec\[new.js\] test script. Functional test -- see my comment above.
5. Tim Statler 2014-09-19 Perhaps this is expected, but filtering out the specs/ folder doesn't fix the runtime errors, since apps require in the specs/index.js file, e.g.

      if (!ENV_PROD) {
      	require('specs/index')($);
      }
      

   Again, we can/do document this issue for users, but I wasn't sure if the expectation was that the filtering would fix the runtime error, which it doesn't.
6. Tim Poulsen 2014-09-19 Ah, good catch. It was not my expectation that this change would catch runtime errors. There are a couple of other ways to handle this besides documenting the issue: * I could add an output message after you create an app with --testapp that reminds developers to remove the require() statement * Or, I could modify the scripts to also copy the testrunner harness files so that the specs would actually run Thoughts?
7. Tim Statler 2014-09-19 I vote for copying the harness files, so it works out of the box.
8. Tim Poulsen 2014-09-19 I updated the PR to copy both the specs and the necessary testing framework files. This new PR also excludes the _generated folder from the set of files copied. Functional test is the same as above, though if you test with the advanced/form_factor you can test that the specs work -- after using alloy new build and run the app. It should run without errors and the app's unit tests should run.
9. Feon Sua Xin Miao 2014-09-22 PR merged.

JSON Source