Backend Project Tests - Sudoku Solver and Am/Brit Translator - Not possible to test from fCC side

Describe your problem and how to reproduce it: I have been working on #37185 (Add Tests for Backend Projects) as I’ve worked though the QA curriculum. I have evaluated the user stories for the Sudoku Solver and American-British Translator and determined that it is not possible to create an FCC hosted test for these projects with any degree of coverage.

The problem is that these two projects are effectively “frontend” projects. Neither has an API nor any significant server-side content. All of the user interaction takes place on the UI, typically in response to user interaction via event handlers.

What I explored

During the time I spent attempting to write my personal unit/functional tests for Sudoku Solver I explored a number of possibilities to enable virtual DOM/headless testing of functional interactions.

JSDOM (current solution) Lacks the ability to trigger events or, if it’s possible, I was unable to get it to work with my code. I tried manually injecting events, but they never fired my handlers. Even if this did work, while it is theoretically possible to run JSDOM natively in the client, doing so opens up the very real possibility of XSS attacks on a user’s fCC profile, assuming we could overcome the CORS issues.

On the server hosted tests I was able to make this work by exporting and manually executing individual handler functions, but only for the unit testing. I was unable to make the Functional tests run with jsdom as they require events to trigger.

Zombie.js I had no better luck getting events to trigger with Zombie.js. The same client-side security issues potentially exist.

Puppeteer (Server Side Only) I ultimately used Puppeteer for functional testing - this launches a headless version of Chrome and programmatically simulates user interaction. I don’t think this would scale well for fCC hosting testing.

Possible Solutions

1. Write two new modules for the front-end testing framework. This is straightforward to do. It just suffers from the same “honor system” issues that all of the font-end projects have.
2. Rewrite these projects as backend with an API. This would be more in the spirit of being more back-end focused. It would reduce the scope of the project somewhat. Having to face the issues of testing with a virtual DOM and/or headless browser are valuable lessons. It would also be silly to put some of the functionality server-side (like character validation).
3. Update the fCC tests to just check the /_api/get-tests end point and parse for passed on various tests. This would require changing the user stories which are displayed on the fCC landing pages to more closely match the verbiage found in the 1_unit-tests.js and 2_functional-tests.js files. This might create some confusion? It is also only slightly better than the “honor system”, although it’s slightly harder to fake that output if we’re counting assertions.

[SaintPeter]

This morning I met with @nhcarrigan and @Sky020 on Discord and we had a detailed discussion about the Sudoku Solver project, in an effort to move it to a more back-end focused project, as discussed in this thread.

We came up with a new concept for the solver which will focus more on understanding the algorithm enough to test it properly by adding a new endpoint /api/check which takes a puzzle, coordinate, and value and determines if it is a valid placement. This seems to be in line with the sort of functionality that an interactive Sudoku solve might have and aligns closely with the goals of the “Quality Assurance” section.

This would also result in a more minimalist front-end which checks the two routes separately. It would have a bit more fCC supplied code to enable the grid->text and text->grid movement, but that’s more of a convivence for the tester then a “feature” of the project and we won’t test for it.

User Stories

1. I can enter a sudoku puzzle by filling in the text area with either a number or period (.) to represent an empty cell.
2. I can POST /api/solve with form data containing puzzle which will consist of the text representation of a puzzle. The returned object will contain solution with the solved puzzle.
3. If the submitted object is missing puzzle, the returned value will be { error: 'Required field missing' }
4. If the submitted puzzle contains values which are not numbers or periods, the returned value will be { error: 'Invalid characters in puzzle' }
5. If the submitted puzzle is greater or less than 81 characters, the returned value will be { error: 'Expected puzzle to be 81 characters long' }
6. If the submitted puzzle is invalid or cannot be solved, the returned value will be { error: 'Puzzle cannot be solved' }
7. I can POST to /api/check an object containing puzzle, coordinate, and value where the coordinate is the letter A-I followed by a number 1-9 and the value is a number from 1-9.
8. The return value will be an object containing valid, which is true if the number may be placed at the provided coordinate and false if the number may not. If false, the returned object will also contain conflict which is an array cotaining the strings "row", "column", and/or "region" depending on which makes the placement invalid.
9. If the submitted puzzle contains values which are not numbers or periods, the returned value will be { error: 'Invalid characters in puzzle' }
10. If the submitted puzzle is greater or less than 81 characters, the returned value will be { error: 'Expected puzzle to be 81 characters long' }
11. If the submitted object is missing puzzle, coordinate or value, the the returned value will be { error: 'Required field(s) missing' }
12. If the coordinate does not point to an existing grid cell, the returned value will be { error: 'Invalid coordinate'}
13. If the value is not a number between 1 and 9, the returned values will be { error: 'Invalid value' }
14. All X unit tests are complete and passing. See /tests/1_unit-tests.js for the expected behavior you should write tests for.
15. All Y functional tests are complete and passing. See /tests/2_functional-tests.js for the functionality you should write tests for.

Boilerplate Functionality

1. Textarea.onchange||.oninput||wahtever works will update the grid
2. grid.onchange will write to the Textarea
3. Add form for /check route
4. DO nothing else because is now functional. Users can optionally make it purdy

[SaintPeter]

Today @nhcarrigan and I updated the user stories on the Sudoku Solver as you had suggested @moT01. Our expectation is that these will ultimately end up in the /learn text, but for the moment they’ll live in the README.md. The Repl.it and GitHub links above have been updated.

We also refactored the American/British Translator project.

Repl.it with code: https://repl.it/@SaintPeter/fcc-american-british-translator-boilerplate-refactor

GitHub Branch: https://github.com/SaintPeter/boilerplate-project-american-british-english-translator/tree/feat/backend-refactor

Note: We do have additional text for the /learn body, which is currently parked in the README.md file.

Please advise what our next steps should be. We are prepared to update the /learn user stories and write the functional tests. Additionally, we can produce an updated example project which will pass those tests using the new boilerplate framework.