Kata

don't like having to invalidate a couple dozen solutions, so hopefully it's good to go at this time.

Don't bother about previous solutions getting invalid. 'Better to have a meaningful task/seutup.

Is it really that important though? For input validation, we're only concerned that the message query / body parameter is set and is a string, so I feel that a few fixed tests addressing those edge cases would be sufficient.

I don't see why it shouldn't be done, actually. It's easy to generate "invalid" queries randomly, so why not doing it? (and preferably in the same batch of tests than the valid ones). I've personnally no strong feelings pros/cons, except for the fact that, if we start to differentiate what we expect for testsing here or there, it might just get more difficult to enforce QA in the beta process.

I don't see how additional random tests would help enforce the specification on this particular kata.

A few downsides to excessive unnecessary tests include less readable output, less clarity about what the scope of the input being tested is, more noise to parse through to find errors and logs, slower submission turnaround and higher maintenance cost. There's a tendency to rely on random tests to enforce parts of the specification that should be done with fixed tests.

My general philosophy is to include the smallest number of tests necessary to ensure no false positives or hardcoded solutions, but no more than that, due to diminishing returns.

Do we have a solution that would pass without sad-path random tests (or any other missing test)? If so, I'd be happy to enforce that with more tests as necessary.

I see what you mean about keeping standards consistent, though. Open to discussion here!

The random tests are never supposed to be there to enforce the specs (except for performances reasons, maybe). They are supposed to forbid hardcoding of the answers.

Caricatural situation: determine if a number is a prime, but never send a prime in the random tests. You'll always end up with users hardcoding the fixed tests and returning false for all random tests (we have a 1 dan user who's a specialist at this...).

I honestly don't know if that's even possible here (hardcoding), but since it doesn't seem hard to implement the error cases...? Unless I'm missing something?

Yep, but it's a common problem that the random tests do overlap part of the spec unexpectedly (and randomly). They're only needed to prevent hardcoding and nothing more, which I believe I've achieved here.

The error case appears to be singular: the message key/param is missing. What would the random tests for this look like that would be any different from the fixed test? I guess they could have different assortments of unrelated keys but I don't see what sort of hardcoded solution scenario this prevents.

Again, I've never used express before today, so you definitely know better than I do on this. I just raised the issue because we generally do so in this kind of situation. If you really think it's not possible to hardcode the fixed tests and abuse the random tests, just close the issue. But again, considering how easy it would be to implement the random errors, I don't see the benefits of making the kata an exception to usual practices.

considering how easy it would be to implement the random errors

Could you provide an example that would be a unique case different from the fixed error tests? I'm having trouble visualizing what the random tests that implement the errors would look like, other than randomly giving the same input that the fixed test already delivers.

Dunno, something like {[randomString()]: randomString()} ? it doesn't need to be that much different from the fixed test (since the goal is to stay consistent with them).

Btw, what would do a request with just {}? Could be "of use" as well?

Gotcha, thanks. I added those tests; I see that a solution that only returns 422 if (req.query.messages) {...} would pass.

I'd like to hear Greg's take on this as well, but as I see it, this Kata could be useful for aspiring JavaScript developers with a basic grasp of the language but are struggling to relate it to real-world programming scenarios. In particular, implementing a trivial Express server might not teach anything about JavaScript language features or problem-solving techniques, but it demonstrates how simple it is to implement a RESTful HTTP API (micro)service using Express and could serve as a stepping stone for embarking on their first real-world Node.js programming project.

Not everything has to revolve around data structures and algorithms; knowing how to leverage real-world programming frameworks in implementing business logic is equally important.

I have nothing against the idea of the kata itself. I actually also think more kata on this kind of topics would be a good idea.

On the other hand, if the intent is "teaching", the current setup has more chances to result in a "somewhat not that pleasant UX", unfortunately. The current setup is perfect as a "test/exam", sort of, to see if someone already knowing the basics actually understood them and can reuse them. But give that to someone who never used express (even if already 1 dan in JS... :cough: ;) ) and there are a little bit too many implicits to tackle to call that "teaching" material, imo.

I see what you're getting at now; with prior experience in similar frameworks like Fastify, I probably underestimated the difficulty of figuring out how Express works from scratch.

If the Kata is intended for someone with no prior experience in implementing RESTful HTTP services, I agree that it would be helpful to mention basic methods for setting the status code and sending the payload, etc., and perhaps even explain the basic components within a typical HTTP request / response.

Good question. I have in mind those who are brand new to Express and don't mind doing independent research to figure out how to solve the problem, as well as those who've gone through a basic Express tutorial or two and need a hands-on challenge to reinforce and extend fundamentals.

It's not a tutorial. There are benefits to tutorials and I thought of making it one but opted not to here. It would add a good deal of verbosity and would be redundant of most Express tutorials. I could add a few documentation references, but didn't want to hand-hold too much in the interest of encouraging independent research.

I edited the description to hopefully clarify this intent a bit.

I also have an ulterior motive in making this kata: I want to provide a minimal example to the Codewars community of how to test an Express app. My hope is that users can build more kata using this setup. So it's a meta-tutorial "how to write an Express kata in Codewars".

If you take a peek at the other Express challenge, you'll see a very different testing approach (which leaves something to be desired since it's using regex to enforce the spec), so as far as I can tell, this is a novel contribution in that sense. In any case, the other Express challenge is a bit more of an Express basics tutorial rather than a test.

I'm not asking for a tutorial, but if you actually aim for those who are brand new to Express, even if they don't mind some individual researches,they could be guided toward some relevant parts of the express documentation. Or the initial solution could be enhanced, for example, providing already the bodyParser parts (which helps a lot to not make this kata a 5kyu task).

Let's do this the other way around. Here are the implicits on which the kata is relying, about express. The user must already know/learn:

• what's the structure of req and res
• how to use them
• the "need" for the body parser thing (not mentionned anywhere / I personnally tried to handle it on my own and got biten by the %20 thing... x) )
• how body parser is behaving with get or post requests
• the fact that the requirements for error handling can be done with one single method while going the other way around is a hassle of another world in comparison

Nothing hard, for sure. But maybe it's not useful to make the user search for hours to solve the task when 2-3 indications/links could reduce that a lot? I mean, if you actually aim at beginners in express, ofc.

In any case, it's your call. I've given my 2 cents on the topic. ;)

It's good to hear the issues you ran into solving this. I thought about including the body parser import, route handler skeletons, or providing itemized links to relevant concepts to make the challenge more approachable for beginners, but it's a design choice to keep it a bit tougher than that.

For a user that has no experience writing a web app, I would expect a few hours' effort and a bit of frustration to reach a solution. This seems normal for learning a brand new library, and I imagine some people enjoy this sort of problem-motivated approach rather than starting with a tutorial. Depending on prior experience, I can see some users ranking this 5 kyu, while others ranking it 7.

My hope is that users find it useful and fair. I'll definitely consider making some of these tweaks if more users feel that it's overly-difficult for what it's asking, or the tests don't match the requirements in any way. For the time being, I think I'll wait to hear a bit more feedback before making difficulty adjustments like these, though. Happy to update wording a bit in the meantime if you have any suggestions. I don't want the tone to come across as "this should be trivial for beginners" when it isn't.

Thanks! I hope to add more examples soon to flesh out some of the sparsely-populated tags.