6 ms·

Generating unit tests in Go

39 points by jyz 11y ago

Zikes 11y ago
This would be great if it were implemented as a "go generate" compatible script or executable. [1] [1] https://blog.golang.org/generate https://blog.golang.org/generate
andrewguenther 11y ago
This is a really poor demo. I opened up the demo page and generated the tests. On first glance, I see a bunch of tests that just verify that the given code does exactly what it was written to do. That misses the _entire_ point of tests. Oh, and only a single test case for each function. Looking a bit more closely, the test cases wouldn't even pass. They're just filled with placeholder values. Okay, fine, the boilerplate is generated, but you have to fill in the expected returns. What about mocks? Why can I only have one test case per function? Also, None of these test cases are documented. You're really still writing the bulk of the tests yourself anyway. I'm not saying there is no value here, but if there is value, that demo shows none of it.
- iofj 11y ago
  Yes, but when have you ever encountered a large company where unit tests are judged by what needs testing as opposed to "coverage" ? There is almost no use for unit tests, as they lock down function implementations without verifying functionality. They have some amount of use for a programmer to verify if what they wrote really is what they wrote, and maybe for data structure methods (not in Go of course), but that means maybe 1 in 50 methods justifies a unit test. Everything else should be system tested, to see if the components fit together and if the interactions between various parts of the application really are what you think they are. It's like javadoc back in the day. "Document all your function variables, you've only got them for x%", ... you write a parser that parses the app and simply adds javadoc everywhere, giving the obvious descriptions to obvious names. 2 hours of work for the generator, but actually interesting work, half an hour to read through it and change a few things, and boom, 30000 lines added in a day. And the worst part is, you've just made everything harder to read, but everybody's happy with you.
  - winstonewert 11y ago
    It sounds to me like you need to stop abusing mocks in your tests. I usually find such tests result from using mocks poorly.
  - eropple 11y ago
    > There is almost no use for unit tests, as they lock down function implementations without verifying functionality. This is...curious, given that every place I've ever been with any sort of testing culture tested contracts, not function implementations. They test the range and domain of the function, not the behavior of it. Unit tests do not replace system-level/integration testing, but to dismiss them out of hand is manifestly unwise.
    - ori_b 11y ago
      Generally, I see a lot of testing of internal functions, which often should change their contract as refactoring happens. All too rarely do I see people focusing testing on public APIs.
      - eropple 11y ago
        It depends on your definition of "internal". I write unit tests at whatever boundary that makes sense, and I certainly will write unit tests to test contracts between related pieces that others might call "internal." But then I can refactor trivially at that level, which I may (read: usually do) want to have available later. I don't generally write, nor really see, see a lot of internal contractual testing in unit testing (not least because it becomes very hard to do so if you actually use visibility in OOP).
  - andrewguenther 11y ago
    > There is almost no use for unit tests, as they lock down function implementations without verifying functionality. I would disagree. You can change the implementation all you want, but you cannot change the functionality (contract). If your unit test verifies implementation rather than functionality, then it is a poor test.
- gkoberger 11y ago
  Based on the footer ("Say no to tests!"), it seems like it's possible that's the whole point? To show how pointless most tests are? (More likely, though, they just mean "say no to writing tests")
donatj 11y ago
For some reason pasting code into it in chrome on Mac, it gets completely mussed up.
mholt 11y ago
500 Internal Server Errors out the wazoo; e.g. http://magictests.com/static/js/bootstrap.min.js http://magictests.com/static/js/bootstrap.min.js
twic 11y ago
I assumed this was a joke about how bad some unit tests are. Then i thought it might be a satire on unit tests, from someone who really thinks they're pointless. Then i realised that this is a demo of a company that someone actually wants to make their fortune with: http://magictests.com/ http://magictests.com/ https://angel.co/magictests https://angel.co/magictests

39 points by jyz 11y ago

Zikes 11y ago

This would be great if it were implemented as a "go generate" compatible script or executable. [1] [1] https://blog.golang.org/generate https://blog.golang.org/generate

andrewguenther 11y ago

This is a really poor demo. I opened up the demo page and generated the tests. On first glance, I see a bunch of tests that just verify that the given code does exactly what it was written to do. That misses the _entire_ point of tests. Oh, and only a single test case for each function. Looking a bit more closely, the test cases wouldn't even pass. They're just filled with placeholder values. Okay, fine, the boilerplate is generated, but you have to fill in the expected returns. What about mocks? Why can I only have one test case per function? Also, None of these test cases are documented. You're really still writing the bulk of the tests yourself anyway. I'm not saying there is no value here, but if there is value, that demo shows none of it.

iofj 11y ago
Yes, but when have you ever encountered a large company where unit tests are judged by what needs testing as opposed to "coverage" ? There is almost no use for unit tests, as they lock down function implementations without verifying functionality. They have some amount of use for a programmer to verify if what they wrote really is what they wrote, and maybe for data structure methods (not in Go of course), but that means maybe 1 in 50 methods justifies a unit test. Everything else should be system tested, to see if the components fit together and if the interactions between various parts of the application really are what you think they are. It's like javadoc back in the day. "Document all your function variables, you've only got them for x%", ... you write a parser that parses the app and simply adds javadoc everywhere, giving the obvious descriptions to obvious names. 2 hours of work for the generator, but actually interesting work, half an hour to read through it and change a few things, and boom, 30000 lines added in a day. And the worst part is, you've just made everything harder to read, but everybody's happy with you.
- winstonewert 11y ago
  It sounds to me like you need to stop abusing mocks in your tests. I usually find such tests result from using mocks poorly.
- eropple 11y ago
  > There is almost no use for unit tests, as they lock down function implementations without verifying functionality. This is...curious, given that every place I've ever been with any sort of testing culture tested contracts, not function implementations. They test the range and domain of the function, not the behavior of it. Unit tests do not replace system-level/integration testing, but to dismiss them out of hand is manifestly unwise.
  - ori_b 11y ago
    Generally, I see a lot of testing of internal functions, which often should change their contract as refactoring happens. All too rarely do I see people focusing testing on public APIs.
    - eropple 11y ago
      It depends on your definition of "internal". I write unit tests at whatever boundary that makes sense, and I certainly will write unit tests to test contracts between related pieces that others might call "internal." But then I can refactor trivially at that level, which I may (read: usually do) want to have available later. I don't generally write, nor really see, see a lot of internal contractual testing in unit testing (not least because it becomes very hard to do so if you actually use visibility in OOP).
- andrewguenther 11y ago
  > There is almost no use for unit tests, as they lock down function implementations without verifying functionality. I would disagree. You can change the implementation all you want, but you cannot change the functionality (contract). If your unit test verifies implementation rather than functionality, then it is a poor test.
gkoberger 11y ago
Based on the footer ("Say no to tests!"), it seems like it's possible that's the whole point? To show how pointless most tests are? (More likely, though, they just mean "say no to writing tests")

donatj 11y ago

For some reason pasting code into it in chrome on Mac, it gets completely mussed up.

mholt 11y ago

500 Internal Server Errors out the wazoo; e.g. http://magictests.com/static/js/bootstrap.min.js http://magictests.com/static/js/bootstrap.min.js

twic 11y ago

I assumed this was a joke about how bad some unit tests are. Then i thought it might be a satire on unit tests, from someone who really thinks they're pointless. Then i realised that this is a demo of a company that someone actually wants to make their fortune with: http://magictests.com/ http://magictests.com/ https://angel.co/magictests https://angel.co/magictests