arsham

Rock In Peace.

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.

Thanks for sharing this awesome article.

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.

Thank you for doing the comparison. Would you do the same against the latest version (v0.5.0) please? Thank you.

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.

Thanks for suggestions :)

Thanks mate, I will definitely have a read.

Cheers mate!

Handling signals are not implemented yet. I appreciate it if you file an issue when you find any. Thanks.

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.

There is a --no-colour/--no-color argument you can pass.

It sounds interesting. Is the language open-sourced?

Can't wait!

Mate, P9k is fantastic, thanks for developing it!