5 ms·

The article is interesting, though a little messy in its structure. I also don't get what the idea is of the JS testing: "I just want to know if some content i

The article is interesting, though a little messy in its structure. I also don't get what the idea is of the JS testing: "I just want to know if some content is or isn’t rendered". Isn't the easiest way to do this to make a request to the URL via the browser and see for yourself? Or am I being unprofessional?

tobyhinloopen 3y ago
> The article is interesting, though a little messy in its structure. Thanks :) I tend to write messy. I'll give future blogs some more revisions to reduce the mess. > Isn't the easiest way to do this to make a request to the URL via the browser and see for yourself? In the applications I'm usually working with, there are many pages, and in many cases they do things differently based on the current context (permissions, roles, state of the business, date) I generally test every route at least twice; one happy flow, and one unhappy flow (trying to submit a form to trigger validation errors, or trying to visit a page you should have no access to), but generally there are many tests per route. I have routes that have literally 1000s of lines of tests for every "real world" case imaginable. Additionally, every bug that's found gets reproduced with a test before it's fixed. The whole web application is usually just gathering params and converting them to domain logic calls, and taking the return value and converting these to a HTML document as a response. The domain logic is fully tested, and the web controller is tested separately by some very basic tests (a simple GET to see if the form fields are present, a POST to see if errors are rendered, and to see if there's no error in the template). Occasionally I will replace the domain logic modules by mocks if the domain logic modules are complex or slow, to keep tests isolated. Because the domain logic modules are tested thoroughly AND the web controllers that invoke the domain logic modules are also tested, most pages (that are backed by modules representing the domain logic) are tested multiple times in different ways. It is not uncommon for me to have widely more LOC for tests than actual code. There's currently 2300 tests in my largest NodeJS project and the whole suite runs in about 30 seconds, but most modules can be tested in less than a second. It is only the "main" module that's slow because it's actually starting the whole application and being tested by actual over-the-network HTTP requests using fetch while the application is also doing real API calls in the background to external services which are mocked in other tests.
- robbiejs 3y ago
  Thanks! 1000 of lines to test a single route? What logic is on the page? I just find it hard to wrap my mind around. No matter how fancy a web page presents itself, isn't it always in essence a form that triggers a thing, like a post to a db?
  - tobyhinloopen 3y ago
    Think of some kind of submission form with lots of conditional fields. There are a lot of these for business to business communications. It's not just the form but also the data it needs to be loading and saving

tobyhinloopen 3y ago

> The article is interesting, though a little messy in its structure. Thanks :) I tend to write messy. I'll give future blogs some more revisions to reduce the mess. > Isn't the easiest way to do this to make a request to the URL via the browser and see for yourself? In the applications I'm usually working with, there are many pages, and in many cases they do things differently based on the current context (permissions, roles, state of the business, date) I generally test every route at least twice; one happy flow, and one unhappy flow (trying to submit a form to trigger validation errors, or trying to visit a page you should have no access to), but generally there are many tests per route. I have routes that have literally 1000s of lines of tests for every "real world" case imaginable. Additionally, every bug that's found gets reproduced with a test before it's fixed. The whole web application is usually just gathering params and converting them to domain logic calls, and taking the return value and converting these to a HTML document as a response. The domain logic is fully tested, and the web controller is tested separately by some very basic tests (a simple GET to see if the form fields are present, a POST to see if errors are rendered, and to see if there's no error in the template). Occasionally I will replace the domain logic modules by mocks if the domain logic modules are complex or slow, to keep tests isolated. Because the domain logic modules are tested thoroughly AND the web controllers that invoke the domain logic modules are also tested, most pages (that are backed by modules representing the domain logic) are tested multiple times in different ways. It is not uncommon for me to have widely more LOC for tests than actual code. There's currently 2300 tests in my largest NodeJS project and the whole suite runs in about 30 seconds, but most modules can be tested in less than a second. It is only the "main" module that's slow because it's actually starting the whole application and being tested by actual over-the-network HTTP requests using fetch while the application is also doing real API calls in the background to external services which are mocked in other tests.

robbiejs 3y ago
Thanks! 1000 of lines to test a single route? What logic is on the page? I just find it hard to wrap my mind around. No matter how fancy a web page presents itself, isn't it always in essence a form that triggers a thing, like a post to a db?
- tobyhinloopen 3y ago
  Think of some kind of submission form with lots of conditional fields. There are a lot of these for business to business communications. It's not just the form but also the data it needs to be loading and saving