[t-writescode]

When writing tests, you can name the methods more useful things, such as:

  class MyTestableClass {
    fun `methodName - when input does not parse to valid regex throw exception`() {

    }
  }

It's pretty clear what is under test in a situation like that. That's basically the only situation I ever see it used in (and would code-smell the heck out of it if I saw it in other circumstances).

People who are familiar with RSpec-style testing are very used to this sort of thing.

  describe MyTestableClass do
    context 'input parsing issues' do
      context 'when not valid regex' do
        it 'throws exception' do
          ...
        end
      end
    end
  end

Anecdotally, I've also found that such style naming for tests allows me to write out the desired names for all the tests ahead of time more easily and then implement them. That happens to be my flow.

[benatkin]

methodName_whenInputDoesNotParseToValidRegexThrowException

They did a study and it isn't hard to read camelCase. https://ieeexplore.ieee.org/document/5090039

[unscaled]

This study only compared camelCase to snake_case and what the results are mixed, depends on what you call "hard to read". They only seem to have tested finding identifiers from a word cloud, and it did take more time to read camelCase identifiers (although they were also resulted in more accuracy).

It's important to note that the researchers only tested short phrases with 2 and 3 words. "getNextPath" is a different beast compared to "methodName_whenInputDoesNotParseToValidRegexThrowException".

On the other hand, there is a good body of research that generally shows that proper sentences (not just 2-3 words) without spaces are harder to read, at least for English speakers[1]. Early medieval Latin manuscripts did not use space between words[2]. The fact that spaces were seen as an improvement when they were introduced, is probably telling.

[1] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=unsp...

[2] Roman-era inscriptions did use an interpunct (a small middle dot) to separate words, but this practice fell out of fashion in Late Antiquity and Early Middle Ages and I'm not sure if it was ever the norm in handwriting.

[yearolinuxdsktp]

From experience CI test reports are vastly more comprehensible at a glance.

That study compared camel case to underscore spaces. Well underscore space is still not as readable as methods with spaces and dashes.

[t-writescode]

Sure, but I like writing the other more. It's entirely a style thing and you're not required to do it :) it's also basically only ever seen in tests :)

[richbell]

I mean, it's harder to read compared to normal text with spaces and punctuation.

[benatkin]

That doesn’t seem to be the case based on the study. And normal for one thing, such as paragraphs of prose, might not translate to another thing, such as a sequence of words in a line of code.

[grapesodaaaaa]

That’s just one study, and I’d argue we should write books in camel case to make them more compact if there’s truly no difference.

[richbell]

> That doesn’t seem to be the case based on the study.

The study does not say that camelCase is unequivocally as easy, or easier, to read.

Selecting the correct identifier from a list of 2-3 words (expandAliasTable, expandAliasTitle, etc.) is a wholly different exercise.

[yearolinuxdsktp]

Ah thank you for actually reading the referenced study

[codedokode]

I like how tests are made in Python - you don't even need classes, just functions, and use a single assert keyword for everything. Also it's easy to parametrize them using decorators.

[stickfigure]

Parameterized tests in Junit are basically the same as decorators:

    @ParameterizedTest
    @ValueSource(strings = {"first", "second"})
    void fooGoesBar(String param) {
        ...
    }

Also, once you get used to assertj, you'll never want single-assert again. It's fantastically useful to know (for example) not just that two lists aren't equal, but specifically what elements differ.

[codedokode]

> It's fantastically useful to know (for example) not just that two lists aren't equal, but specifically what elements differ.

Pytest shows the diff as well when using assert:

    >       assert y == x
    E       assert [1, 2, 3] == [1, 4, 3, 6]
    E         
    E          At index 1 diff: 2 != 4
    E         Right contains one more item: 6
    E         Use -v to get more diff

[stickfigure]

Great, what's the equivalent of this?

    assertThat(someCollection).map(Thing::getValue).containsExactlyInAnyOrder(3, 4, 5);

[codedokode]

If the list contains numbers or strings, you can use

    assert sorted(x) == sorted(y)

If you want to add map, then you have to write

    assert list(sorted(i.getValue() for i in someCollection)) == [3, 4, 5]

If the list contains non-sortable values, but they are hashable and unique, you can use sets:

    assert set(x) == set(y)

If the values are not unique, but hashable, you can use a counter (like a set but with count for repeating values):

    assert Counter(x) == Counter(y)

(by the way I learned about this trick from a LLM)

And if the values are neither sortable, nor hashable, you'll have to write a helper function.

But still, pytest tests are less wordy and they don't require you to create a class.

This situation is familiar to me, I had to write such helper function when writing tests in PHP, for some reason it is not included in PHPUnit assertions.

[t-writescode]

Parameterized tests are a huge, huge win, yeah. I am a big fan of them and look for how to do them in every test framework I use. RSpec was the weirdest for me; but NUnit and JUnit have been quite easy, and I'm not surprised at all they're easy in Python too (admittedly, I don't remember if I ever wrote them in that language).

[karmakaze]

In the RSpec case, those don't have to translate to method names with embedded spaces. It seems that using fun `...` instead of a dsl: test "..." is the mistake.