Structure of test files for generated exercises? about dart HOT 12 CLOSED

Well...I feel offended. By saying that about your solution, you're implying my solution is also not clever.

I'm sure your solution is WAY more clever than mine! :-D

Regarding the class based final wordCount = WordCount(); approach. I feel that we'd be forcing learners to always opt-for OOP.

Ah, that's in no way enforced. We can put whatever we want in the initialization, I meant only in terms of the grouping (main, groups, tests).

from dart.

Thanks!

Okay, so it looks like this is the structure that you'd like:

Basically, all the tests in a single group, regardless of whether they are grouped differently in the problem-specifications canonical-data.json file, correct?

I am working on making a (mostly) language-agnostic generator that would only require a small language-specific add-on.
I've used it to update most of the exercises in the Ruby track, and generate exercises for the Chapel track. If you're okay with having a flat structure with all the tests in a single group, that simplifies things considerably.

from dart.

Ah!, the reason why I wasn't notified is because @kabiir is no longer my username. I don't have access to that account. This has happened quite a few times 😅 .

If you're okay with having a flat structure with all the tests in a single group, that simplifies things considerably.

I would be okay because it simplifies things. Since we can always iterate and as you mentioned a small language-specific add-on can help tune things to match the track's taste.
I now understand the changes in #412. The current structure of allergies exercise is pretty nice too. It creates logical grouping without additional functions (hard to generate) like in word-count. If your generator is open-source, I might be able to contribute :). I have done my fair share of dart specific as well as not so specific code generation in the past.

from dart.

This has happened quite a few times

Oh no! I will try to pay attention so I ping you with the right username.

Right now my generator is a big messy pile of scripts that would make your eyes bleed. Once I figure out what functionality it needs to work across most tracks, it will definitely be reworked to be a standard tool for Exercism. I would love to have your help with the dart-specific bits. For now I'm making due with hacks and auto-formatting, which is... I mean, it totally works, sort of 😂

from dart.

The toml is used only to identify which tests to include, not to generate the tests. I can group the tests based on the canonical data.

from dart.

To conclude about the test structure:

If there are multiple groups of cases in the problem-specifications, we'll extract out the groups into named functions.
If there is just one, we will inline it and just use a closure.

Multiple groups

import 'package:test/test.dart';
import 'package:word_count/word_count.dart';

final wordCount = WordCount();

void main() {
  group("WordCount: Simple Tests - ", simpleTests);
  group("WordCount: Ignore special characters - ", ignoreSpecialCharacters);
  group("WordCount: Works with numbers too - ", notJustWords);
  group("WordCount: Edge case - ", edgeCases);
}

void simpleTests() {
  // ...
}

void ignoreSpecialCharacters() {
  // ...
}

void notJustWords() {
  // ...
}

void edgeCases() {
  // ...
}

Single group

import 'package:test/test.dart';
import 'package:two_fer/two_fer.dart';

void main() {
  group('TwoFer', () {
    // ...
  }
}

from dart.

I suggest looking at the create_exercise.dart under the bin directory.

It is used to create exercises based on problem specifications, though it may use some updates.

If it works generally well, then we could refactor it to update existing exercises.

from dart.

Basically, all the tests in a single group, regardless of whether they are grouped differently in the problem-specifications canonical-data.json file, correct?

That will work

from dart.

After looking over the changes to allergies, I do think if the toml can be used to denote groups of tests, then I would prefer that as it seems that's how the allergy exercise is structured. But if toml can't, then this is fine until a dart plugin/extension can be created.

from dart.

Right now my generator is a big messy pile of scripts that would make your eyes bleed. Once I figure out what functionality it needs to work across most tracks, it will definitely be reworked to be a standard tool for Exercism. I would love to have your help with the dart-specific bits. For now I'm making due with hacks and auto-formatting, which is... I mean, it totally works, sort of 😂

I would've described our create_exercise.dart script the same way. The world of software runs on such scripts anyway!
At some point I started re-writing that script (I think last to last hacktoberfest). I never got to finishing it.

My idea was to rewrite the script as a template (handlebars, mustache, jinja, etc) renderer. The template context could simply be the canonical-data.json with some goodies injected to make the template authoring painless.
For example apart from the exercise_slug available as a context variable, I added it in other string cases as well, so ExerciseSlug and exerciseSlug would work as expected.

See the example test template written in mustache/handlebars.

import 'package:test/test.dart';
import 'package:{{exercise_slug | snakeCase}}/{{exercise_slug}}.dart';

/// The following uses a pipe as well as pre-defined context variables
final {{exerciseSlug}} = {{ exercise_slug | pascalCase }}(); // final wordCount = WordCount();

void main() {
  {{#cases}} // Loop over all cases
      {{>define_test_case}} /// Define the top-level cases as in the case of hamming exercise
      
      /// Nested cases if defined
      {{#.cases}} /// If this exercise has nested cases (grouping), iterate over each and define it in the style of word-count.
          /// `sentence` is a function
          group("{{ExerciseSlug}}: {{ sentence .description }} - ", {{ .description | pascalCase }}Tests);
      {{/.cases}} 
  {{/cases}}
}

{{#cases}}
void {{ .name | pascalCase }}Tests() {
    {{#cases}}
        {{>define_test_case}} // a partial defined separately
    {{/cases}}
}
{{/cases}}

I am curious to know what your approach is.

from dart.

It's more or less the same 😂 {{exercise_slug}}, {{ExerciseSlug}}, {{exerciseSlug}}, {{exercise-slug}}, and {{exercise slug}} all work.

I have a pre-processing step that generates a new data.json that is specific to the language, and some base templates that help put the pieces together, and you can override certain things. It's not clever, and it sometimes needs a bit of handholding, but it's very pragmatic and works surprisingly well.

from dart.

It's more or less the same 😂

I see. We share a brain cell 🤣

It's not clever

Well...I feel offended. By saying that about your solution, you're implying my solution is also not clever.

To conclude about the test structure:

Regarding the class based final wordCount = WordCount(); approach. I feel that we'd be forcing learners to always opt-for OOP.

Not an easy way to solve this (i.e. if you even think of that as a problem). But one possible way comes to mind.

We could support multiple test files. One for each paradigm that is supported by the programming language. As a learner, I would want to mix things up sometimes.
Or sometimes, I would be already well versed with the problem and the language but want to learn about a paradigm. In that case learning about the paradigm would be much friction-less.

When multiple test files is not possible, your generator can come in handy since it's really rendering files. It would make it possible to support multiple versions (paradigms) of templates and try to distribute all versions equally among all exercises per track.

However, this might not be the intended use-case of practice exercises.

from dart.