Streamline the process of adding new apps

[Mazyod]

Instead of manually writing new Swift classes, tests, pod specs, and modifying the readme, we can have a configuration file with all the apps specs we have, and then a script that generates all the files needed. This will help us move much faster and adapt to future changes more quickly.

Tasks

• Design the configuration files
• Script the Swift source files generator
• Script the Pod Subspecs generator
• Script the readme table generator

[Dreamersoul]

Right now the design for the config files looks solid, 75% of the swift file is being generated (The app's actions are not being generated yet), generating the readme would be relatively easy along with the pod specs.

The python scripts should be tested right? (if so I need directions with what library or method should I use)

Also, I'm thinking generating tests is a risky thing to do, what do you think @Mazyod ?

[Mazyod]

😄 Great question! .. I've been thinking about generating unit tests for the swift code, but that would simply useless, since a bug in those files would mean a bug in the script! So, yeah, testing the scripts would be our priority.

Regarding the library to use, I love using py.test, but if you want to keep dependencies to minimum, we can use unittest module in python itself.

As for a general direction, we need some integration tests and perhaps some unit tests, as described below:

File Structure

General file structure. [TEXT] is a generic placeholder to use as a template.

tests
 |
 +--> appz_scripts
 |    |
 |    +--> appz_models_tests.py
 |    |
 |    +--> [FILENAME]_tests.py
 |
 +--> integration
      |
      +--> generate_swift_files_test.py
      |
      +--> [INTEGRATION_NAME]_test.py

Unit Testing

Unit testing is optional. You can do it for tricky functions. For example, if you have a function that does a complicated string transformation, you can write a unit test for that function and test different input. I looked at your approach, and I think Jinja is doing all the complicated stuff, so unit tests are probably not needed.

Integration Testing

This is very tricky, but super important, especially for testing the swift files generation. I will use that as an example of how to write the integration test.

So, let's say you prepared the Jinja template, and fed it some JSON config, and a swift file was generated. How can we know that this whole process, from start to finish, worked well? That is what an integration tests helps us do.

So, in the case of the swift files, we need to simply compile the file and execute another swift file which uses the generated swift file!

e.g.

JSON -> Twitter actions
Generated file -> Twitter.swift
IntegrationTests.swift ->

app.open(Applications.Twitter(), action: .status("1"))

So, a python test script would possibly use subprocess call to prepare the swift files, compile them, and simply make sure everything compiles correctly. We can go further to run the final swift file and see if the output works, but that's even more tricky.

---

In all cases, I think the testing part is very challenging, I don't even know if it will simply work as described. I can give you a hand and work on the tests in parallel (on Saturday), and then we can simply run the tests against your output.

[Dreamersoul]

Thank you for the comprehensive response, once I finish from the code generation code I will try to get a head start with testing and compiling swift files. 👍

[Dreamersoul]

Swift files are being generated now perfectly, Although I will refactor some of the code later since it doesn't follow theDRY (don't repeat yourself) principle.
I will test if the code is producing the right code tomorrow but for now, you can check my repo on branch streamline.
should I create a pull request now or when I test it with different config files?

[Mazyod]

awesome, will check them out as soon as I can. You can always open a PR, and we can keep it open till it's ready.