I understand the author wants to compare the options but I cannot resist to leave a few comments here:
1. I'm not against test libraries/frameworks. In fact I've used Ginkgo and it is fantastic. Some people have came up with clever ways to create those lib/frameworks, but learning another library doesn't come close to enhancing your ability to write better tests.
2. Repetition is the nature of writing tests. In fact, the more you write the same code for testing different parts of the logic, the more strong your API will get. I mean when you make a mistake, you will break more tests. The drawback is you need to know the API well, otherwise you'll face refactoring hell.
3. The more you get near to standard library in general, the more new-comers to your code understand it. You cannot assume everyone knows the library you use in your code, but you can be sure if they are reading your tests, they know a bit of Go and that is quite enough.
4. Table driven tests help with reducing repetition and is so much fun. You can also add more test cases in only one line in the future if you need to. Here is my take on testing the code in the article:
func TestOperations(t *testing.T) {
tcs := []struct {
name string
a, b int
f func(int, int) int
want int
}{
{"Add 1 2", 1, 2, tmp.Add, 3},
{"Subtract 5 3", 5, 3, tmp.Subtract, 2},
{"Multiply 5 6", 5, 6, tmp.Multiply, 30},
}
for _, tc := range tcs {
t.Run(tc.name, func(t *testing.T) {
result := tc.f(tc.a, tc.b)
if result != tc.want {
t.Errorf("result = %d, want %d", result, tc.want)
}
})
}
}
Of course this is for a trivial program. In real world you find yourself test more complex functions and you will create one Test... function for each function.
5. The happy path of tests in BDD style frameworks are indented way too much. This distracts you a bit from the test logic.
I've also switched to Opera a couple of months ago. I'm running Opera touch on android too. I've found Opera on desktop (Linux) to be faster than Firefox and Chrome and the only functionality I'm missing is "to move the tabs to left and right". Even the chromecast works on Opera, which is fantastic.
I've been using the Flow functionality ever since I've started using Opera, and I think that is the second reason (well, after it being fast) I'm going to stick with Opera.
That is correct. The project is at its early stages. I want to see what the community need the most and shape the project towards that goal. On the other hand I tried to avoid optimisations until most of functionalities are implemented.
It's a very nice idea and you should be proud of what you've built, but my personal opinion is that speed is a core feature of `grep`.
A good place to start would be this: why GNU grep is fast[1] - Starting with the Boyer-Moore string search algorithm and reading through the optimizations done in GNU grep.
p.s. there's an implementation of Boyer-Moore hiding in Go's standard library.
So far I've been only concerned about code's simplicity until I understand what there needs to be done. This is not going to be grep or ripgrep. My intent was to make a tool I needed so I started working on it. I thought someone else might like it, now it is joyful to see people are looking at the project.
There are a couple of places I wish I would have done better. Using bufio.Scanner actually bothers me a lot. Also in the Read() method it reads everything from all readers into a buffer instead of pulling what it needs to check.
Given the relationship between eul author and deadlines it won't happen in 2018. Author also promised to open-source eul itself at first but last statement is "I'm not 100% sure it's going to be possible."[0]
Current state of eul app also hinting that most likely nothing of value would be lost if this language won't be open-sourced.
