Abstract:

In recent years, there has been a growing interest in making education widely accessible using Internet technologies. Whether it is Massive Open Online Courses (MOOCs) or simply college courses offered to a large student population using an online platform, both education-focused companies and universities, often in collaboration with one another, have been investing massively in online education. The fact that hundreds, and more often thousands, of students take these online courses raises scalability challenges in assessing student assignments. In this paper, in particular, we present a technique (GUITestMigrator) that addresses the challenge of assessing mobile app coding assignments. Given a set of apps that implement the same specification, but can have completely different user interfaces, instructors normally have to manually run and check each app to make sure it behaves correctly and according to the specification. GUITestMigrator, conversely, allows for developing tests for one of these apps and automatically migrating these tests to the other apps, thus dramatically reducing the burden on the instructor. We implemented GUITestMigrator for Android apps and evaluated it on three sets of apps developed over three different semesters by students of an online graduate-level software engineering course. Our initial results show that our approach is promising and motivates further research in this direction. The paper also discusses possible applications of this approach for test evolution and test migration for real-world apps.

Grocery List Manager

Requirements:

1. A grocery list consists of items the users want to buy at a grocery store. The application must allow users to add items to a list, delete items from a list, and change the quantity of items in the list (e.g., change from one to two pounds of apples).
2. The application must contain a database (DB) of items and corresponding item types.
3. Users must be able to add items to a list by picking them from a hierarchical list, where the first level is the item type (e.g., cereal), and the second level is the name of the actual item (e.g., shredded wheat). After adding an item, users must be able to specify a quantity for that item.
4. Users must also be able to specify an item by typing its name. In this case, the application must look in its DB for items with similar names and ask the users, for each of them, whether that is the item they intended to add. If a match cannot be found, the application must ask the user to select a type for the item and then save the new item, together with its type, in its DB.
5. Lists must be saved automatically and immediately after they are modified.
6. Users must be able to check off items in a list (without deleting them).
7. Users must also be able to clear all the check-off marks in a list at once.
8. Check-off marks for a list are persistent and must also be saved immediately.
9. The application must present the items in a list grouped by type, so as to allow users to shop for a specific type of products at once (i.e., without having to go back and forth between aisles).
10. The application must support multiple lists at a time (e.g., “weekly grocery list”, “monthly farmer’s market list”). Therefore, the application must provide the users with the ability to create, (re)name, select, and delete lists.
11. The User Interface (UI) must be intuitive and responsive.

Videos of the Source App's Tests:

GoBowl

Requirements:

1. The bowling alley manager uses the system to (1) add customers, (2) print customer cards, and (3) edit customer information. For simplicity, we assume that the manager is the only employee working at the bowling alley.
2. The bowling alley customers use the system to request lanes and checkout when done playing.
3. A customer in the system is characterized by the following information:
   1. Name
   2. Email address
   3. 4-digit unique hexadecimal ID
4. When a customer is added to the system using his/her name and email address, the system automatically generates an ID and prints a card for the customer. The card is printed using a special card printer that is accessed through an external library.
5. The customer card contains a QR code that can be read using a videocam attached to the system and that encodes the customer’s unique ID.
6. The process to request a lane works as follows:
   1. A customer launches the “Lane request” functionality.
   2. The system scans the customer card.
   3. The system asks the customer for the number of players.
   4. After the customer enters the number of players, the system requests all players to scan their cards, one at a time (only registered customers can play).
   5. The system assigns a lane to the players and shows the lane number on screen (assume that there is an unlimited number of lanes for now).
7. When a group of players is done bowling, the checkout process works as follows:
   1. A customer launches the “Checkout” functionality.
   2. The system asks the customer for his/her lane number.
   3. After the customer enters the lane number, the system asks whether any player wants to save his/her score. If the answer is yes, the system shows the list of players for that lane and allows the customer to select any of them and enter a score. When a score is entered, the system adds the score, together with the current date, to the list of scores for the selected player. This process continues until the customer indicates that he/she is done entering scores.
   4. The system then asks how the players want to split the bill for the lane (from 1 to <number of players> ways).
   5. Once the players enter a number, the system splits the bill evenly and asks to swipe as many credit cards as needed, charging the right amount on every card. (All payments are by credit card. No cash payments are allowed.)
8. The cost of a lane is:
   1. $20/hour from 9am to 5pm, Mon, Tue, Thu, Fri.
   2. $25/hour from 5pm to midnight, Mon, Tue, Thu, Fri.
   3. $30/hour all day on Sat and Sun.
   4. $10/hour all day on Wed.
9. A credit card scanner attached to the system allows the system to read, when a card is swiped, (1) the cardholder’s name, (2) the card’s account number, (3) the card's expiration date, and (4) the card's security code.
10. All the hardware devices attached to the system (card printer, videocam, and credit card scanner) can be accessed through existing external libraries. Similarly, external libraries enable the system to connect to a payment-processing service provider that can process credit card transactions. You must model each of these external libraries as a utility class (i.e., a class marked with the stereotype “<<utility>>”) with one or more suitable methods.
11. Customers can use any credit card they want to perform a purchase (including someone else’s card, if that person is present). In other words, (1) the credit card information does not have to be associated with the customer in the system, and (2) the credit card information should not be stored after the transaction is completed.

12. Customers who spend $500 or more in a single calendar year achieve VIP status, which entitles them to a 10% discount on the cost of the lanes for the following year. The change of status is effective from January 1 of the following year, and the customer has to be the one requesting the lane to get the discount. The discount applies to the whole cost of the lane.

Videos of the Source App's Tests:

TCCart

Requirements:

1. The tea and coffee cart manager uses the system to (1) add customers, (2) print customer cards, (3) edit customer information, (4) process purchases, and (5) keep track of purchases and rewards. For simplicity, we assume that the manager is the only person working at the cart and using the system.
2. A customer in the system is characterized by the following information:
   1. Name
   2. Email address
   3. 8-digit unique hexadecimal ID
3. When a customer is added to the system using his/her name and email address, the system automatically generates an ID and prints a card for the customer. The card is printed using a special card printer that is accessed through an external library.
4. The customer card contains a QR code that can be read using a videocam attached to the system and encodes the customer’s unique ID.
5. All payments must be performed using a credit card. No cash payments are allowed.
6. A credit card scanner attached to the system allows the system to read, when a card is swiped, (1) the cardholder’s name, (2) the card’s account number, (3) the card's expiration date, and (4) the card's security code.
7. All the hardware devices attached to the system (card printer, videocam, and credit card scanner) can be accessed through existing external libraries.
8. Similarly, external libraries enable the system to (1) connect to a payment-processing service provider that can process credit card transactions and (2) send email messages.
9. Customers can use any credit card they want to perform a purchase (including someone else’s card, if that person is present). In other words, (1) the credit card information does not have to be associated with the customer in the system, and (2) the credit card information should not be stored after the transaction is completed.
10. The system should send an email receipt to a customer every time he/she completes a purchase.
11. Every time a customer spends $30 or more in a single purchase, he/she gets a $3 credit towards his/her next purchase as a reward. The following rules apply:
    1. The credit expires after a month.
    2. The credit is applied towards the very next purchase; that is, a customer cannot choose to save the credit and use it for a subsequent purchase.
    3. To get the $3 credit, the customer must actually pay $30 or more; that is, the amount is computed after any existing discount and existing credit is applied. For example, if a customer buys $32 worth of tea and coffee and has a $3 credit, he/she would actually spend $29 and would therefore not get the $3 credit for that purchase.
    4. If the cost C of the purchase is less than the current credit for that customer, the credit is decreased by C. For example, if the current credit is $3, and the cost of the purchase is $2.5, the customer pays $0, and the remaining credit is $0.5.
12. The system should send an email to a customer when he/she gets a credit.
13. Customers who spend $300 or more in a single calendar year achieve VIP status, which entitles them to a 10% discount on every purchase for the following year.
    1. The change of status is effective from January 1 of the following year.
    2. The discount is applied before any other discount or credit is applied.
14. The system should send an email to a customer when he/she achieves VIP status for the following year. This email should be sent as soon as the customer qualifies for the VIP status, even if the change of status won’t occur during the current year.
15. At any particular point in time, the tea and coffee cart manager should be able to display, for any customer in the system, a complete list of their transactions. For each transaction, the tea and coffee cart manager should be able to see (1) date, (2) amount of purchase before discounts, and (3) whether discounts or credits were applied (i.e., which ones, and for which amount).

Videos of the Source App's Tests:

Supplementary Materials:

You can download the source code and the experimental data and infrastructure from here.