This can be a challenging question to answer. I see a lot of people with experience in just doing UI test automation without getting involved in API testing or full-stack test automation, so there may not be a lot of answers to this question. Also, not everything can or should be tested via the UI.
First, it's going to be beneficial to understand that not everything can be tested via automation, nor should everything be tested via automation. It'll also help to understand the Agile Test Pyramid to understand the different levels on where to apply test automation.
- is it possible to automate test the phone call functions
I would say that this is one of those areas where it is not feasible to do test automation. What phone number are you going to call? Do you call a virtual phone (e.g. a Google Voice number) or a real landline/mobile phone? How do you verify that a call was successful? You can't have any automation that picks up a landline or mobile phone. If you use a Google Voice number, you could use Selenium to perform actions on their app, but then you're stuck on what to assert when you answer a call? How would you validate the audio is active? FYI: This might be against Google's Terms of Service, so you need to really check that this is legal with those terms and you should check with your company's legal department on this
If this occurs, then you're at the mercy of Google and they may change things you can't account for, so that means a lot of updates/maintenance on your end to keep up with Google's changes. Is that worth the time and money to do this? In my opinion, it's not worth it.
- if not how can I make most of CI/CD ?
Understand the differences in test automation within the tech stack and the Agile Test Pyramid. It's also good to understand the concept of "separation of concerns."
You should use test automation on the UI to validate that the UI is working. But, if you click the phone call button, the UI test automation does not need to validate the phone call has been made. You just need to validate if it calls the appropriate API function.
You need to be using automation for API tests separate from UI tests. And you need to be using mocks to verify proper responses. I can't see how to do this without mocks!
From a CI/CD perspective, you use it just like you normally would on any build or test scenario. You ensure your unit tests are run; you ensure your integrations tests run; you ensure your UI tests are run. If any test fails, the build stops and reports the error. Some tests may take longer, but that's not an issue with CI/CD systems. I think of CI/CD like a highway system: there are no inherent changes you need to make based on type of vehicle present (vehicle = test in this case), and the highway will work for all types.
For a personal example, I once tested smart TVs. (Yes, this isn't about phones but the concepts are similar.) The software you use on a smart TV is just a web app running on a localhost server (being the physical TV). For this, it was easy to run the web app on my local computer or CI/CD (a TV wasn't needed.) How do I then test that a TV remote worked on this web app? You can't use a mouse or a keyboard to navigate. The TV remote just communicated via REST APIs, so I ensured that the APIs had their own test automation. I was then able to call those APIs in my automation and mock a response for my specific test cases. When you're integrating with physical hardware or network/telephony protocols, utilizing mocks is the best way to handle test automation.
Another example, I'm working on a project now that is heavy on APIs using a micro-service architecture. We rely on dozens of 3rd party API integrations. Here, I have zero control over those 3rd parties so, in order to create test automation, I have to create mocks and simulate their API payloads to ensure my team's software work correctly.
When you test each layer separately and really get those tests in a solid state, you'll prevent bugs from bubbling up to the surface. Then, you can concentrate on integration points between those layers (have the UI call/mock the APIs or have unit tests call/mock the APIs).
Additionally, look for examples from other companies. Twilio/Zipwhip and Zendesk are all about using a web app to perform phone calls and SMS messaging. See if they have tech blogs or conference talks detailing how they solved this problem because they absolutely use test automation and mocks for this.
In further searching, Twilio uses a form of mocking they call "Magic Numbers". These can be used by their internal dev teams and any dev team wanting to integrate with them using their APIs. Magic Numbers are virtual numbers that do not correspond to any landline or mobile phone. The idea behind mocking, Magic Numbers, etc is that if your software works here, it will work with real phone numbers. This is an easier and faster approach then using real phone numbers.
Sorry for the long answer. This is a challenging problem to solve that goes beyond a typical web app implementation.
