The Sneaker Inventory project is a website that will allow users to market their sneaker collection. While the intention of the site isn't to allow for actual resell, the goal is to have this webiste act as a repository for any of the many exeisting reselling sites. The fundamental features of this webiste include displaying and sharing sneaker inventories, as well as having access to other features such as current market value.
A HTML/CSS/VanillaJS (subject to change to React/Vue) front end will allow users to access and update details regarding their sneaker collection. This interface will have a login page, inventory access not limited to adding, viewing, and sorting their collection based on a variety of filters. It will also allow users to upload pictures that will be associated with a specific entry. Users will also be able to see the current price of individual items or their whole collection based on data extracted from (StockX). Additionally, if time allows, there will be a feature for following other users and adding accessbility to their inventories.
Data regarding sneaker collections will be stored in a MySQL database, and communication with the frontend will be aided by a Spring Boot web service. There will be data associated with a member’s personal account and details regarding their sneaker collection. Browser Automation of stockX to retrieve current market value will be done with Selenium web driver and Scaping will be done with JSoup or HtmlUnit. Member details for the database will include (Name, Account number to be used as primary key, date joined and a reference to their collection, number of items in collection). Data kept regarding sneakers includes (brand, model, SKU number, price, size and purchase date).
FOR Sneaker Enthusiast WHO Collect, buy and sell sneakers THE Sneaker Inventory is a web based service THAT provides inventory tracking, current value tracking, and sharing collection to community. UNLIKE using excel spread sheet to track inventory OUR PRODUCT let users easily track current value of their sneaker collection and share it with others.
- Java (Main program)
- MySQL and JDBC (Database)
- Spring Boot (Web Service)
- Selenium (Browser Automation)
- Jsoup/HtmlUnit(Web Scraping)
- HTML/CSS/JavaScript (GUI where user will input and view their inventory)
As the project is built from the ground up, the only way to really test was to write code for results. As functionality was added to the database, each function was tested for accuracy and consistency.
The above block shows various functions the database needs to handle. By changing the values, we were able to see how accurately data entered the tables and how reliable the code was at retrieving data by comparing expected results with real results. Here we found out SQL calls were case sensitive, and others were not. This meant Strings were not handled in a uniform manner meaning case now becomes a defining identifier, which we did not want.
We learnt SQL in java, SQL in mySQLWorkBench and SQL Developer handle data types differently, so code needed to be implemented in a certain way to account for how java handled the Strings that would become the SQL queries/statements. Example, a table create statement in MySQLWorkbench would not execute in java because of how certain data types were defined and some constrained were not supported.
Testing for Frontend webpage was done manually. Since Frontend of webpage was mostly visual in website, testing was done for each page by clicking buttons and see if click redirect to supposed page with correct link. Page was also reviewed to see if the output rendered on each page was correct. For forms that require input from user, testing was done by clicking submit buttons without user input and see if page displays correct error messages, and with correct input whether correct success message pops up.
Web Service json
Testing the web service and most importantly the endpoints was done using two different technologies. The most used testing resource was Postman, which was used to verify that the correct address was being requested at, while the correct headers cookies and body were being responded with. Postman was used both locally and through a team workspace using collections and documenting tests. The second technology used was Curl. In the beginning stages this was used to test simple endpoints on the localhost. As the service was deployed onto ec2 it became to difficult to retain sessions and redirects so we turned to postman.
The Service used much of the database code and implementation required constant revision of the databasemanager class. To do so successfully, temporary driver classes were needed to test that the correct information was being passed into any model classes, and associating a proper response based on the output from the database class