4 ms·

Generics is the big news, but the fuzzing support is amazing too. I added a fuzz test to an app I have in about 5 minutes. It was no harder than adding a norma

Generics is the big news, but the fuzzing support is amazing too. I added a fuzz test to an app I have in about 5 minutes. It was no harder than adding a normal test. I expect to see a huge boon in users of fuzzing techniques which will benefit projects across the board.

staticassertion 5y ago
I'm very happy to see fuzzing added to Go, and I don't write Go at all (or every plan to). Bringing concepts like this to the masses is a win for everybody.
sneak 5y ago
Link to the diff? I always learn better by concrete example than by docs.
- nwsm 5y ago
  The docs have concrete examples if you want- https://go.dev/doc/tutorial/fuzz https://go.dev/doc/tutorial/fuzz
2OEH8eoCRo0 5y ago
Nobody at my work has even heard of fuzzing and thought I was making it up. I'm glad senior SWEs are paid so much to keep up with the industry. /s
- movedx 5y ago
  I don't consider those kinds of people engineers at all. They're people who have learned a syntax, some patterns and, thanks to their human brain, can adopt it slightly to certain situations. But they're not engineers. Engineers constantly ask why, explore the unknown and are aware of almost all possible solutions available to them. using this knowledge they select the correct tools and build the solution. What you've described are skilled labourers. I'm harsh with my judgement because I believe our industry has a lot of "statically minded" individuals who stay in their lane, never going outside their boxes, to explore what else is out there to help them solves the engineering problems they're faced with... and it's pissing me off :)
  - rr808 5y ago
    Engineers are people who can create a solution to a problem in an efficient and effective way. Specialists who know every detail are craftsmen who can create the best possible solution but they aren't necessarily good engineers.
    - movedx 5y ago
      > Engineers are people who can create a solution to a problem in an efficient and effective way. How do you create an "efficient" and "effective" solution if you're not aware of as many options as possible, i.e. fuzzing for security vulns? How is your solution "effective" if I can throw a bunch of Unicode at an input field and crash your application because the "engineer" didn't know what fuzzing is?
      - BoorishBears 5y ago
        Sure is a lot more effective if they're good at communicating and actually meet business needs... Not every application needs to have 99.9999999% uptime. There is plenty of honest to goodness productive output coming out of "shit" codebases that just tackled one use-case after another, never giving a care about some weirdo dumping in a bunch of unicode.
      - rr808 5y ago
        I've seen a common pattern of specialist devs who can write loads of code and complex tests, but never actually talk to a user or check if the software is doing what the users really want.
grogenaut 5y ago
Did it break anything/uncover anything?
- justinsaccount 5y ago
  Pretty much, yeah. I knew I needed some extra sanity checks around input parsing and sanity checking shorter than expected buffers. Fuzzing the function that parsed input caused panics and other errors that I was able to fix by adding bounds/sanity checks in the right places.
Cthulhu_ 5y ago
I might use fuzz testing to test some validation logic I will add later on, things like strings having to match a certain pattern. Regex is Klatchian to me, but the previous guy left behind a big set of expressions that are currently used in validation; using fuzz testing I should be able (if I understand it correctly) to find gaps in those expressions.

staticassertion 5y ago

I'm very happy to see fuzzing added to Go, and I don't write Go at all (or every plan to). Bringing concepts like this to the masses is a win for everybody.

sneak 5y ago

Link to the diff? I always learn better by concrete example than by docs.

nwsm 5y ago
The docs have concrete examples if you want- https://go.dev/doc/tutorial/fuzz https://go.dev/doc/tutorial/fuzz

2OEH8eoCRo0 5y ago

Nobody at my work has even heard of fuzzing and thought I was making it up. I'm glad senior SWEs are paid so much to keep up with the industry. /s

movedx 5y ago
I don't consider those kinds of people engineers at all. They're people who have learned a syntax, some patterns and, thanks to their human brain, can adopt it slightly to certain situations. But they're not engineers. Engineers constantly ask why, explore the unknown and are aware of almost all possible solutions available to them. using this knowledge they select the correct tools and build the solution. What you've described are skilled labourers. I'm harsh with my judgement because I believe our industry has a lot of "statically minded" individuals who stay in their lane, never going outside their boxes, to explore what else is out there to help them solves the engineering problems they're faced with... and it's pissing me off :)
- rr808 5y ago
  Engineers are people who can create a solution to a problem in an efficient and effective way. Specialists who know every detail are craftsmen who can create the best possible solution but they aren't necessarily good engineers.
  - movedx 5y ago
    > Engineers are people who can create a solution to a problem in an efficient and effective way. How do you create an "efficient" and "effective" solution if you're not aware of as many options as possible, i.e. fuzzing for security vulns? How is your solution "effective" if I can throw a bunch of Unicode at an input field and crash your application because the "engineer" didn't know what fuzzing is?
    - BoorishBears 5y ago
      Sure is a lot more effective if they're good at communicating and actually meet business needs... Not every application needs to have 99.9999999% uptime. There is plenty of honest to goodness productive output coming out of "shit" codebases that just tackled one use-case after another, never giving a care about some weirdo dumping in a bunch of unicode.
    - rr808 5y ago
      I've seen a common pattern of specialist devs who can write loads of code and complex tests, but never actually talk to a user or check if the software is doing what the users really want.

grogenaut 5y ago

Did it break anything/uncover anything?

justinsaccount 5y ago
Pretty much, yeah. I knew I needed some extra sanity checks around input parsing and sanity checking shorter than expected buffers. Fuzzing the function that parsed input caused panics and other errors that I was able to fix by adding bounds/sanity checks in the right places.

Cthulhu_ 5y ago

I might use fuzz testing to test some validation logic I will add later on, things like strings having to match a certain pattern. Regex is Klatchian to me, but the previous guy left behind a big set of expressions that are currently used in validation; using fuzz testing I should be able (if I understand it correctly) to find gaps in those expressions.