I am writing functional tests for my application that scrapes some data online then sends the results in an SMS text (on a weekly basis). My understanding is that functional tests are meant to test the functionality from the users' point of view. So, how do I "test" that the user receives a text? I am using Twilio API. Also, how do I test that the user is receiving the text weekly? Am I thinking about this wrong?
How to Test User Receiving a Text – Unit and Functional Testing
functional-testingunit testing
Related Solutions
Functional tests are generally used as a synonym for integration tests. You may be confusing the unit tests with functional tests if I understood your question correctly.
In unit tests, aim to test the function itself in isolation, by mocking/stubbing other components.
In integration tests, test different systems working together, to see if they work together correctly to produce the correct output.
For your example send_invite, in unit tests, you can mock the email and other framework components, and just test if the send invite function correctly calls the email component with correct arguments. For the integration tests, you can set up a testing server and see if the function correctly sends emails and does everything it supposed to do, including the other components.
Unit tests are the smallest testing block, followed by the integration tests.
EDIT:
Let's leave the words aside and approach the problem as why we need tests. We need tests to ensure our code is working correctly.
In the send_email example, first we need to test the function in isolation to see it does what it supposed to do. We do this by isolating the function from other components by mocking/stubbing to test the function itself. Assuming we have a different component that is responsible for sending emails, and our function is calling this component to send emails, if our email component is broken, we won't want this to affect the test of send_email, it's not directly related to this function. We just want to make sure the code in the send_email function is working correctly. That is generally called unit testing.
After we are sure the function is working correctly in isolation, we need to test if the invitation system is working correctly, with all of it's components. This time we do it by testing the function without mocks/stubs. This is generally called integration tests.
In some places, there are functional tests with side effects and functional tests without side effects, which means calling the function with predefined arguments in tests without mocking/stubbing to see it produces the correct output, and calling the function with predefined arguments in tests with mocking/stubbing other components, respectively. This can translates into unit tests and integration tests.
The language can be confusing, and different cultures/communities sometimes call these tests with different words. What needs to be done in testing is, starting testing with the smallest meaningful unit possible, and work from there to whole system.(This can be done in reverse order too, but it's out of the scope of this answer)
Best Answer
You're using a third-party API, so you don't need to spend a lot of effort to automate testing the functionality provided by that API. You need to focus testing on your application's interactions with that API.
One set of tests can be written against the API documentation. Looking at the documentation, what are the valid responses from the API? If you mock out the third-party API and replace it with mock responses, does your system behave as expected given the response?
Another set of tests can used captured actual responses from the API and ensure that your system is handling the actual messages. You could combine this with the first approach, as well and capture real responses in different sets of success and failure cases and use those in testing.
Some APIs also have test credentials. It appears that Twilo provides this. In some cases, they may have different, test-specific endpoints that they maintain to allow you to test different scenarios and get simulated responses. This can also be useful in test or other demonstration environments.
You should have monitoring and logging (of the parameters to and responses from) the third-party API. You can perform some manual testing in a pre-production environment, probably using the test credentials. Monitoring in the production environment can also provide information to report defects to the vendor.