I gave it a try, my "quick" solution was 15 lines and despite thinking I have it and tests will pass, i ran tests twice during that and they failed, only on the 3rd try it was passing. Were just minor tweaks that were necessary like adding a space between the words but still, unexpected test failures.
In case this comment understands markdown, and someone is interested to look at my solution:
```java
if (text.contains(" ")) {
String[] strings = text.split(" ");
Map<String, Integer> map = new HashMap<>();
for (String string : strings) {
if (map.containsKey(string)) {
Integer integer = map.get(string);
map.put(string, integer + 1);
} else {
map.put(string, 1);
}
}
String result = "";
for (Entry<String, Integer> entry : map.entrySet()) {
result += entry.getKey() + "=" + entry.getValue() + " ";
Fascinating, Lars -- thanks for doing this. What's most interesting for me is the constant stream of tiny stresses; I want to work without those digging at me all of the time...
Of course, there IS a way to get that test passing very quickly, with only a tiny change:
if (text.equals("happy monday")) return "happy=1 monday=1";
I wonder why it is that we feel the need to do so much design, instead of just writing this trivial solution...?
Hypothesis: we can do so much design because for some problem we can visualize a generalized solution up front. But what if the problem is difficult enough, involving calling object collaborators or other functions that don't exist yet, in an outside in fashion. Then the TDD cycle remains feasible but upfront design might not be, or might be wasteful as it's continuously redone.
Agreed Giorgio. But I suspect the stronger force here is our desire to write "good" code. And because of that strong desire, we are reluctant to write "bad" code first -- even if it will only survive for a few minutes until we refactor.
There may also be a desire to get it "right first time" and avoid "rework". If I "know" what the better design will look like, why not just write it down now and save all of the faff. It can be very difficult to be methodical enough and strict enough to take the tiny steps implied by TDD's rules.
I gave it a try, my "quick" solution was 15 lines and despite thinking I have it and tests will pass, i ran tests twice during that and they failed, only on the 3rd try it was passing. Were just minor tweaks that were necessary like adding a space between the words but still, unexpected test failures.
In case this comment understands markdown, and someone is interested to look at my solution:
```java
if (text.contains(" ")) {
String[] strings = text.split(" ");
Map<String, Integer> map = new HashMap<>();
for (String string : strings) {
if (map.containsKey(string)) {
Integer integer = map.get(string);
map.put(string, integer + 1);
} else {
map.put(string, 1);
}
}
String result = "";
for (Entry<String, Integer> entry : map.entrySet()) {
result += entry.getKey() + "=" + entry.getValue() + " ";
}
return result.trim();
}
```
and now refactored using streams:
```java
if (text.contains(" ")) {
return Arrays.stream(text.split(" "))
.collect(Collectors.groupingBy(Function.identity(), Collectors.counting()))
.entrySet().stream()
.map(c -> c.getKey() + "=" + c.getValue())
.collect(Collectors.joining(" "));
}
```
Fascinating, Lars -- thanks for doing this. What's most interesting for me is the constant stream of tiny stresses; I want to work without those digging at me all of the time...
Of course, there IS a way to get that test passing very quickly, with only a tiny change:
if (text.equals("happy monday")) return "happy=1 monday=1";
I wonder why it is that we feel the need to do so much design, instead of just writing this trivial solution...?
Hypothesis: we can do so much design because for some problem we can visualize a generalized solution up front. But what if the problem is difficult enough, involving calling object collaborators or other functions that don't exist yet, in an outside in fashion. Then the TDD cycle remains feasible but upfront design might not be, or might be wasteful as it's continuously redone.
Agreed Giorgio. But I suspect the stronger force here is our desire to write "good" code. And because of that strong desire, we are reluctant to write "bad" code first -- even if it will only survive for a few minutes until we refactor.
There may also be a desire to get it "right first time" and avoid "rework". If I "know" what the better design will look like, why not just write it down now and save all of the faff. It can be very difficult to be methodical enough and strict enough to take the tiny steps implied by TDD's rules.