7 ms·

> As far as I can tell you can’t step through tests in the debugger Rant time. What to do when you write a test framework. 1. When test fails, print everythin

• gouggoug 9y ago
  Slightly related: The lack of an easy to use debugger is a huge issue for me when working with go. Coming from PHP, I spend 90% of my time in the debugger running my code line by lines (with xdebug coupled to phpstorm). A debugger is especially useful when working with other's people code and large softwares. For example, contributing to large Go projects like Kubernetes can be daunting due to the very steep learning curve. This curve would be greatly reduced if we had a good reliable go debugger, which doesn't seem to be the case at the moment. (I'm aware of delve, but last time I looked, it was still fairly complicated to have it work).
  • abledon 9y ago
    How is the debug experience in elixir compared to go ?
    • hlieberman 9y ago
      Erlang/Elixir debugging is world-class. You can directly instrument functions running in production with fairly little overhead. I highly suggest reading "Erlang in Anger" by ferd/MononQC. It (and his recon library) are indispensable tools for people running Erlang or Elixir in prod.
      • hak8or 9y ago
        How on earth is it world class if you can't do line by line or step debugging?
        • hlieberman 9y ago
          You can? The Erlang debugger has been there since at least R10....
    • deleted 9y ago
      [deleted]
    • bitwalker 9y ago
      Elixir does an amazing job of showing you why a test failed, but as for debugging, up until the latest release, 1.5, there wasn't really a debugger, it had pry, which lets you play around in the environment at the point where pry is called, but you can't step though code. 1.5 introduced a more useful debugging experience, but you can't step line by line, you can only step from breakpoint to breakpoint as far as I'm aware, but I haven't played much with it yet. It's getting there though! I should note that I haven't really lamented the lack of a good debugger, and I came from .NET where I had one of the best debuggers available.
      • ramchip 9y ago
        Erlang's graphical debugger works with Elixir since OTP-19 (last year). See this page after the section on Pry: http://blog.plataformatec.com.br/2016/04/debugging-techniques-in-elixir-lang/ http://blog.plataformatec.com.br/2016/04/debugging-technique... It supports stepping, etc.
  • pkroll 9y ago
    How long ago was that? 'cause it seems pretty easy to get running now, even on Windows.
    • justinclift 9y ago
      Delve only works on Linux, OSX, and Windows. Not at all on *BSD. ∙ Delve works "ok-ish" on Linux. Sometimes breakpoints don't fire (for me), but generally it's mostly usable. ∙ Windows and OSX both have issues with (at least) cgo code. ∙ The lack of BSD support is just because no-one's contributed the native bits yet: https://github.com/derekparker/delve/tree/master/pkg/proc/native So, it'll probably get done at some point in the future. As an example of the problems, a basic search on the Jetbrains issue tracker for Gogland (which includes Delve) shows many, many, many bugs filed. https://youtrack.jetbrains.com/issues/GO?q=debugger eg breakpoints not firing, variables being shown outside their scope, variable names being incorrect, debugging session just hanging (etc) That being said, the problems are getting looked at and fixed, both by the Delve dev's, the Jetbrains people for things where Gogland can help, and in Go itself when problems originate there (incomplete DWARF info on some OS's for example). Go 1.9 (due for release any day now) helps with the variable scope problems. Still, it's a long way from "just works" to the level C developers are used to. Though it's improving. Personally, I really wish the "just works" was already here. :D
  • jchw 9y ago
    Have you looked at Delve? I haven't personally tried it, but it works well with VS Code for line by line debugging. I've strangely found success without even worrying about line by line debugging. Typically, unit tests and the occasional printf debug has done well enough for me.
  • erikbye 9y ago
    https://www.jetbrains.com/go/features/ https://www.jetbrains.com/go/features/
  • tmaly 9y ago
    there is a debugger for Go https://github.com/derekparker/delve https://github.com/derekparker/delve you can step through things and print stuff out
• sergiotapia 9y ago
  This is why I love Elixir. It comes with tests as a first-class citizen. Colors! Line numbers! Visual grep! DEVELOPER UX. Check this out: http://i.imgur.com/qDPE9Pc.png http://i.imgur.com/qDPE9Pc.png
• codyb 9y ago
  Came out of private mode on my phone to upvote this. One key point I'd like to add though is that you must _always_ run git diff before committing anything. There's been enough times where that has saved me from erraneously committing logging statements that are absolutely unnecessary post bug fix.
  • davidbanham 9y ago
    Getting into the habit of always adding via `git add -p` is useful to stop this from happening.
    • codyb 9y ago
      Yea commiting by hunks is also super useful. I find a lot of engineers only have a cursory understanding of a lot of git. Rebase vs merge throws a lot of people off and not a lot of people know about git bisect which is just incredibly useful. I think some of it is that people like the graphical nature of things like sourcetree which while offering pretty interfaces don't fully flesh out git. Give me the command line any day.
      • concede_pluto 9y ago
        It's better to do the big commit and then refactor it. Otherwise you won't have tested whether the hunks depend on each other, which means history littered with broken commits.
  • osteele 9y ago
    You can also use a different function for temporary debug prints, and a git pre-commit hook that fails if this function is invoked. Pros: Easier to insure that your collaborators follow process; your CI server can run it too. Con: This doesn't catch other issues that a manual `git diff` review will also catch.
• frik 9y ago
  "Golang drops GOPATH" - I am waiting for this headline. The biggest hurdle with Golang and working on different unrelated projects that are in their own GIT repo. Golang forces you to have one single path were all the code should reside - GOPATH. Name me one other language that has such a restrictive requirement. Why not offer a config?? Beside that I like everything else about Go a lot.
  • rquirk 9y ago
    In my project I use "env GOPATH=$PWD go ..." in the makefile, that way it all goes in the current directory. There's probably some good reason this is a bad idea, but go is kinda funky anyway so I make up my own best practices :-)
    • petepete 9y ago
      Have a look at virtualgo https://github.com/getstream/vg https://github.com/getstream/vg
  • jchw 9y ago
    The GOPATH system blows for the learning curve, but it's good for a lot of other reasons, like being very simple to understand and reason about. I don't really enjoy the way Node.js and Python handle package management personally, because it can get complicated. But I've wondered why someone hadn't wired up Go with an npm style package manager, since it would totally be doable. The Go team does seem to care about the problem though, and they at least made a sane default Go path of $HOME/go, so you can go get right away.
  • boomlinde 9y ago
    > The biggest hurdle with Golang and working on different unrelated projects that are in their own GIT repo. Golang forces you to have one single path were all the code should reside - GOPATH. No one forces you to have one single path where your code should reside. It's just an environment variable, so you can have a GOPATH set per project if you wish. It could be your git root. > Why not offer a config?? That's what they did, or what am I missing?
  • 9y ago
• flashmob 9y ago
  > As far as I can tell you can’t step through tests in the debugger Actually, you can, if your IDE lets you. Eg. In Intellij if you're using the Go plugin, you will see little green arrow in the margins of your tests. Set a breakpoint and click the little arrow. The new Gogland IDE has this too.
• masklinn 9y ago
  > Like, you do 'assert.equals(x,y)', and it doesn't even show you what the values of x and y are, let alone figure out that maybe "x!=y" would be an obvious thing to print. That's why pytest is my buddy. You don't use any odd method, you just write `assert x == y` and if it fails it tells you that it fails, and what the operands were: def test_py(): a = geta() b = getb() > assert a == b E assert 7 == 467 if you add an assertion message, it just gets added to the output: def test_py(): a = geta() b = getb() > assert a == b, "assertion message" E AssertionError: assertion message E assert 99 == 343
  • jchw 9y ago
    Wow... I am using Django's stock test runner and that makes me jealous. I've wished I could just write python asserts and have it print useful information. Of course, this technique only works in dynamic languages. In Go I use testify assert and that is good enough for me.
    • louthy 9y ago
      > Of course, this technique only works in dynamic language It can work in any language that supports reflection, dynamic or not.
      • nothrabannosir 9y ago
        Or macros, or just direct language (i.e. compiler) support.
    • masklinn 9y ago
      > Of course, this technique only works in dynamic languages. Actually, pytest does that by rewriting the AST[0], basically it rewrites the `assert` statement into a more complex form which extracts all the info it needs upon failure. In a statically typed language, you could do that with a compilation hook and some codegen. There used to be a "reinterpret" mode where it would walk the stack frame and try to understand the expression involved at runtime, that was removed in Pytest 3.0, now the choices are assert-rewriting and plain assert (without any introspection). [0] http://pybites.blogspot.be/2011/07/behind-scenes-of-pytests-new-assertion.html http://pybites.blogspot.be/2011/07/behind-scenes-of-pytests-...