Right now, I'm working on an overhaul of an edit page for a menu, which is quite involved in and of itself. I have identified the issue: there is literally no structure in place for when a user selects a category, or none at all, to adjust the contents of the item and category selector modals. Also, HTML elements on those modals were being shown/hidden on filtering/searching, rather than being removed from the DOM completely.

I tackled the problem as follows: adopt an MVC-ish solution:

  • have a menuState, that drives the page, to handle adding/removing items/categories from the view, no matter where the end user is at on the menu (all the way at the top, or nested within subcategories). Abstract out the handling of the data itself by implementing this as IIFE and exposing methods to get/edit the data accordingly
  • item and category selection modals are generated via Mustache template, that renders, with data passed to them whenever a user takes an action (opening the modal, entering some search keys, filtering). Add in pagination, via template partials, to handle the issue that happened in a real-world scenario when a client had literally thousands of items to choose from, and have events on those.
  • for each of the modals, have a controller that invokes the appropriate methods of menuState, and handles the actions upon the view (changing the page, filtering the data, ...).


Everything works, except for menuState: when I wrote menuState, I didn't know all the business requirements (for example, I didn't know we could have subcategories, or no categories, to add data to, and that I would have to handle it). Also, I had no means of quickly testing all these use cases, to ensure no bugs/regressions. (Since I'm now refactoring, there's bound to be regressions.)

Also, I know of, and have experience with, unit-testing, but my exposure to unit-testing the front-end is limited to copying and pasting code under test into a testing environment with Mocha. After some research, I found a well-written article about unit-testing front end, but it is covering the scenario when the front end is written using a framework (React). Unfortunately, we don't use any such framework, so I went to try to find other means of testing. I stumbled upon an example that uses exports.

We don't export any units of work, especially when they are only used on one page (in my case, despite menuState being an IIFE, it is only defined for the menu-edit page on which I am working.)

What are my options for testing this unit of work, including in a TDD-friendly way?

  • Could you detail the tech stack a bit more? How are the pages created? What does the user have on his browser? Jan 29, 2019 at 5:57

2 Answers 2


Since you cannot leverage the testing tools of modern framework, such as React or Ember, I would suggest the following:

  • Focus on application level checks:

    • Using Selenium, most widespread. Example here:

      • driver.get("http://www.google.com");
        WebElement element = driver.findElement(By.name("q"));
    • Or using Cypress, less used, by with some advantages over Selenium.
  • If possible, try to go down a bit and test units of Javascript code, using UnitJs, for instance.

  • That second bullet point, is literally what I'm trying to do: to test menuState, a unit of JavaScript code. Jan 29, 2019 at 12:59
  • UnitJS can be good then. But don't get discouraged is you can't make it work. Small and focused application level checks are still useful for driving dev and regression. (If you find the answer acceptable, could you mark it as accepted?) Jan 29, 2019 at 13:02
  • Can you provide a sample use case? My group's code lives in ./static/js/[path to code], and all content is served either from the static folder, or from our middle layer (Golang). Jan 29, 2019 at 14:46

Your question is too broad for a good short answer. But I suggest you have a look at 7 days trial of https://www.letscodejavascript.com/

An in-depth screencast about Test-Driven JavaScript, which programs a Sketch Drawing application in VanillaJS called WeeWikiPaint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.