Collecting the project requirements was fairly simple. Prof. Connor wanted a system to deploy Voiceflow bot designs to SMS. After a few discussion rounds, we settled on the following requirements:
|Discover a method to export chatbot data out of Voiceflow, OR, research Voiceflow alternatives||Must|
|Research the best platform for building SMS bots||Must|
|The SMS bot should be no/little code environment||Must|
|Design a stable bot data format||Could|
|Design a stable API for SMS backends||Could|
|Produce implementations of these APIs for your chosen platforms||Could|
|Document, test, and publish them as isolated ||Could|
Most importantly, this project is about research. The end result is clear, but it is unknown how to achieve it in a viable manner. We need to clarify how we receive and process Voiceflow data, as well as how can we create SMS chatbots using that data.
Proposing A Better System Architecture
As we developed the project, we saw that we largely depended on external APIs, backends, and file formats. All of these are prone to change. Also, if someone wants to adapt our project to a different chatbot data input (e.g. not Voiceflow) or a different SMS backend, they would have to change many aspects of the project. Also, the project was developed initially as a monolith application with little room for extensibility and few ways in which other developers can reuse some aspects of it in their work. Though this was fulfilling all of our client’s requirements, it seemed we could do a lot better here for the future aspects of the project.
We came up with the idea to split our project into 3 entities, standardise its APIs and data formats, provide concrete implementations of these standards, and publish them as self-contained software packages to be reused by other developers. Our client appreciated this progress and we added that to our optional requirements.
Once that is done, we can proceed with creating a functional system:
|The ability to convert any Voiceflow bot into an SMS chatbot with the same functionality||Must|
|Deploy the SMS chatbots under a specific phone number that can be chosen from a set of numbers||Must|
|The ability to dynamically remap different chatbots to different numbers||Must|
|User-facing application deployable on Windows / Mac environments or via a web API||Must|
|If is is via a web API, it should sit on a Linode platform and be deployable via Docker||Must|
|The ability to remove deployed chatbots||Should|
|The ability to log errors||Should|
|If the solution is not standalone, enable a Voiceflow user to apply the solution via multiple browsers including Chrome and Explorer||Should|
|The ability to test a chatbot as if it was deployed on SMS||Could|
|Have unit tests for core business logic||Could|
|Have 95%+ code coverage for all business logic||Could|
|Have full system E2E tests and test all probable system workflows||Could|
|Have UI unit tests for all UI pages||Could|
|Have full UI E2E tests (including business logic) and test all probable user pathways||Could|
|Create 100% fail-proof input validation to guarantee that if the system accepts an input, it will be interpreted correctly||Could|
The client proposed the
must requirements. As the project developed, our team proposed to add all
could level requirements. Our reasoning follows.
We proposed to add a requirement to test bots before SMS deployment. The idea is to simulate a chat interface for the user to text the bot as if it was already deployed. We thought that it was an important part of the system in order to guarantee safety before deployment. The client agreed.
Business Logic Testing
We wanted to guarantee that all of our business logic code works in all edge cases. This is why we placed a target of 100% code coverage for unit tests. In addition, because we wanted to separate our business logic in self-contained
npm packages, making sure they work perfectly in isolation is key too. This is why, for every software package, we also aim to develop extensive full-system E2E tests that test every possible workflow of the library.
If the business logic modules are properly designed and isolated, then the UI code would simply call these functions and make it pretty. Therefore there isn’t much that “could go wrong” for a test to detect in a reasonable amount of code.
Nonetheless, we decided to go and write unit tests for all UI pages. This is an administrative UI, so however basic (in terms of logic) it is, we must guarantee that the pages/buttons/actions do what they should and that the views are updated accordingly with state.
In addition, we also decided to implement full UI E2E tests. These would simulate a real user clicking buttons and reading text from the screen and then navigating and achieving complex tasks. Tasks that require a sequence of steps, so would not be covered by mere unit tests. We think this is important to guarantee that after everything else, the whole system works as expected.
Our business logic represents two self-contained modules. These modules have inputs. The inputs are very complicated, representing multiple file format specifications. Nonetheless, we must guarantee that a module rejects an input that doesn’t fit this exact format.
For example, it could be that our external chatbot data source changes their format very slightly. We must be able to detect that and refuse to process it until a developer has confirmed that the software correctly interprets the new format.
In short, the client asked us to produce a user-facing application with Create, Read, Update, and Delete operations over SMS chatbots, and the respective research and implementation of some business logic.
In addition, we decided to greatly expand the requirement set with the aforementioned requirements. We could have stuck to the initial requirements and delivered them 2x faster. Therefore, we think this is worth noting as it shows the determination of our team to produce a good, impactful piece of software.