5 ms·
When writing tests, you can name the methods more useful things, such as: class MyTestableClass { fun `methodName - when input does not parse to valid re
by t-writescode 2y ago
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.
- codedokode 2y agoI 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.
- t-writescode 2y agoParameterized 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).
- stickfigure 2y agoParameterized 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 2y ago> 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 2y agoGreat, what's the equivalent of this? assertThat(someCollection).map(Thing::getValue).containsExactlyInAnyOrder(3, 4, 5);
- codedokode 2y agoIf 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.
- benatkin 2y agomethodName_whenInputDoesNotParseToValidRegexThrowException They did a study and it isn't hard to read camelCase. https://ieeexplore.ieee.org/document/5090039 https://ieeexplore.ieee.org/document/5090039
- richbell 2y agoI mean, it's harder to read compared to normal text with spaces and punctuation.
- benatkin 2y agoThat 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.
- richbell 2y ago> 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 2y agoAh thank you for actually reading the referenced study
- grapesodaaaaa 2y agoThat’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.
- t-writescode 2y agoSure, 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 :)
- karmakaze 2y agoIn 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.