Mockery

Overview

Test data is a vital requirement throughout the entire development of any web application. The data must be real; not in the sense of the data having any type of semantic correlation to the external world; but real in the sense of its syntactic structure and internal references. Generating this data can be a time-consuming process that is subject to a great deal of change, especially early in the software development cycle.

Mockery : A Mock Repository

This project will develop a web application that allows users to specify, create, and persist large mock data-sets that can be exported for their own use. While that data-sets can be used for any purpose, they are intentionally delivered via a web-api with the intended use-case being that of web application development.

There is at least one online site that provides functions similar to what we propose. Mockaroo is able to generate mock-data and enables the user to download it in a variety of common formats. We propose to support the functional behavior of Mockaroo in addition to persisting the data via a user-programmable api with user-controlled endpoints.

Any student who is insterested in web development (security, authentication, user roles, JavaScript, web design) and no-sql databases (MongoDB in particular) will be a likely candidate for this project.

Functional Requirements

The following is a short list of functional requirements for this system. This project will require the student to develop a more complete set of functional requirements.

Roles

There are two roles for this system: admins and users.

Admin

As an admin, I want to be able to

• Log in
• Log out
• Edit my profile
• View the profiles of all users
• Edit the profile an any user
• Search for a user using any combination of email, username, first name and last name
• View the endpoints of all users
• Enable and disable any user (not including admins)
• Make any user an admin

User

As a user, I want to be able to

• Log in
• Log out
• Edit my profile
• Create/Edit/Delete an endpoint. An endpoint is created by specifying
  • the path, method, and query parameters
  • the semantic structure (schema) of the retrieved data. The schema must support numerous pre-defined semantic data types including: users, departments, Universities, names (segmented on gender, first, last, and ethnicity), social security numbers, phone numbers, dates, credit-card numbers, images (dummy images of specified dimensions).
  • the format. Must support JSON and CSV
  • whether or not the data is permanently persisted or regenerated on each call.
• Associated with each endpoint is an automatically created form for interacting with that endpoint.