Web Service Testing a Chat Room GUI and API
Web Service Testing a Chat Room GUI and API
Read through a thought experiment that outlines the moving parts of and the steps needed to test a chat management service.
Join the DZone community and get the full member experience.Join For Free
SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.
I like to show how web service testing works, and I find that the best way to do this is by introducing a particular sample app, then brainstorming out loud what needs to exist in the background to make it all work. So, as long as I’m on the topic of talking about things, I thought I would use a chat room website as my sample app. The chat website portal will require someone to log in or register, so this is the first action we’ll need to decide how to enable through web service testing.
Next, we’ll figure out the kinds of actions we’ll be communicating, and the parameters that will need to be passed. The chat room website will, in fact, be a front-end GUI for checking membership and managing chat rooms. At entry, people will be asked to log in as current members (parameters: username and password), or be given a chance to register as a new member (parameters: email, username, and password).
Let us begin by discussing the new member. The new member enters an email, username, and password. The password is entered twice, and the GUI is smart enough to ask for corrections if the passwords differ, if any field is blank, if the password or username exceed 40 characters, or if the email does not have a proper email format. If the message makes it through all of that with no problems, the web service sends a message to what we’ll call AddMember. AddMember will respond with two parameters; the first is “Approved” or “Rejected,” and the second is the username. If the response is “Approved,” an email will be automatically sent to the new member. The only reason for rejecting a username would be that it is already registered in the system. The GUI politely informs the user of the result, either by welcoming them as a new member by username, or by telling them to submit a new username because theirs is already taken.
If the user is a returning member, the GUI warns if either field (username or password) is empty. Otherwise, a web service we’ll call CheckMember gets called. The CheckMember request has two parameters (username and password), and the response is also two parameters (the first is “Approved” or “Username not found” or “Wrong password,” and the second is the username). The GUI politely informs the user of the result, either welcoming them back by username, or telling them “Could not log in as [username] because: [Reason]. Please try again.”
Let us assume that we have now managed to log in. Yay! OK, that’s enough excitement for now; we now have access to other functions. Another web service message (parameter: username) goes out, which we’ll call CheckChats. The responding web service message returns the username and a text string of any upcoming scheduled chats. If any of the listed chats is scheduled for five minutes from now or within the past hour, the member will be given the chance to enter the chat, where they will call the web service JoinChat by using two parameters: their username and the chat ID. Three parameters get returned with the new third parameter identifying the success of joining the chat (0 indicates failure). If you’re in a chat, you can exit using ExitChat, which uses the same request and response parameters as described for JoinChat.
Oh, I almost forgot the most important part! As I said, the whole purpose of the website is to manage chats, so this ability exists, of course. Through the GUI interface, you can schedule chats. You may access any of the following: NewChat, ReschedChat, AddChatMember, DeleteChatMember, and RemoveChat. NewChat has the request parameters username and datetime. The username is the one you logged in with, not one you specify, and datetime must be within the past five minutes or in the future, and returns your username and a chat ID as response parameters (Chat ID is 0 if it fails). ReschedChat and RemoveChat work the same as NewChat. AddChatMember and DeleteChatMember have request parameters of your username (forced), the chat ID, and the member you wish to add or delete from the chat, the response is the same as the request if successful, and just the first two parameters if it fails. Replacing a chat member would generate both a DeleteChatMember and an AddChatMember. Any of these actions, of course, will also result in an email being sent to the users who are impacted by these changes.
I hope you’ve enjoyed reading my example here of how web services can be used to implement all of the behind-the-scenes work for a chat website. It is important to realize all of the actions you need to have, on the user side as well as the supporting back-end necessities.
Opinions expressed by DZone contributors are their own.