5 ms·

I've recently joined a team that focuses massively on test-driven development, and it's just such a great way to shake out dumb bugs and focus on the requiremen

I've recently joined a team that focuses massively on test-driven development, and it's just such a great way to shake out dumb bugs and focus on the requirements and the problem you're trying to solve. Also recently did Thorsten Ball's Interpreter/Compiler books which focus heavily on unit testing the functionality (I can't recommend these books enough). I now can't imagine going back to a pre-TDD world

fjp 7y ago
I did Learn Go With Tests which was my first intro to TDD and I found it enjoyable even if the author is little overly pedantic about his preferred testing approach. However at work, I often find that I feel like I can't write unit tests before starting code because I just don't know how it's going to get built until I start poking at the code. I'm not sure how to break out of this
- citrablue 7y ago
  What does your pre-code design process look like? Might beef that up; its what has helped me quite a bit.
- mandeepj 7y ago
  > However at work, I often find that I feel like I can't write unit tests before starting code because I just don't know how it's going to get built until I start poking at the code. I'm not sure how to break out of this You'd start with shallow functions and quality asserts. Initially, you'd have broken tests, you have to write code to fix them, and that's your TDD.
  - tcbasche 7y ago
    This is definitely the best way. Start with the how you want everything to look and make your code match your expectation.
    - quii 7y ago
      Hello, I wrote learn go with tests! Your comment is exactly what I try to get across in the book but it's not always easy. If you cant decide how you want something to look (as that's not always easy) just take a punt on something. Make sure it's a small decision and make something useful. Sure you might have to change it, but at least you'll be basing that on some real feedback.
      - fjp 7y ago
        Hi, thank you for writing the book! Great introduction to Go. One thing I was uncomfortable with about TDD is the step to "just write enough to make the test pass". The danger seems to be when you have to walk away from some code and you or whoever picks up your code doesn't know what you were up to. In a simple app and a few tests you could probably tell, but the larger an application gets, the less you can put effort into finding out "this test works because the application works how it should" or "this test works because someone wrote just enough code and hardcoded some value somewhere in order to make the test pass". It seems "safer" to write tests that are going to stay broken until every little corner of everything works properly, even though this is less iterative. As mentioned above I have little TDD experience, so maybe I'm missing something.
        quii 7y ago
        The point of "just writing enough to make the test pass" is to get you to the point where you have working software (proven by the test, even if the code is "bad") This is the _only_ point where you can safely refactor, if your tests are failing how do you know you haven't broken something? So long as you keep things "green" you know you're ok > The danger seems to be when you have to walk away from some code and you or whoever picks up your code doesn't know what you were up to. Just don't do this. You're not "done" with the TDD cycle until you make it pass and have refactored. I reflect this in my git usage too, roughly it goes - Write a test -> Make it pass -> git commit -am "made it do something" -> refactor -> run tests (if i get in a mess, revert back to safety and try again) -> git add . -> git commit --amend --no-edit > It seems "safer" to write tests that are going to stay broken until every little corner of everything works properly, even though this is less iterative. The problem with this is how do you safely refactor when you have potentially dozens of tests failing? A big point of this approach is it makes refactoring a continuous process and makes it easier because you have tests proving you haven't accidentally changed behaviour.
- twh270 7y ago
  I'm not even thinking about "how it's going to get built" when I write test-first. I'm just writing (test) code as a client that's calling an API. It just so happens that the API (method, or method + object) in question doesn't actually exist yet, so the first thing I do is let the IDE generate them so it compiles. Once the code compiles I go into the implementation and make it work. Now and then I realize during implementation that I need some additional parameter, but it's easy to add that.
  - fjp 7y ago
    I guess to me: 1) Writing a test that calls an API and asserts that everything resulted correctly from it is more of an integration test in my opinion - in this case I can agree this can be written beforehand. 2. If I'm changing my tests as I write my code then it doesn't matter if I go test-code-test-code vs code-test-code-test. I have still changed my definition of "correct" on the fly based on something I found out as I implemented.
dmux 7y ago
How have you achieved a balance between too little and too much testing? I worked on a project that had a ton of tests, but they seemed to be "over fitted."
- tcbasche 7y ago
  The trick is to get something covered to the point where you could comfortable refactor the bejeezus out of it, and know that it's still working from a higher level. The test should be how you know the code works, and under any situation. That is, you don't need to test that inbuilt standard library stuff is working as expected (e.g does a string reverse) but rather, does the combination of possible inputs match your expectations?

fjp 7y ago

I did Learn Go With Tests which was my first intro to TDD and I found it enjoyable even if the author is little overly pedantic about his preferred testing approach. However at work, I often find that I feel like I can't write unit tests before starting code because I just don't know how it's going to get built until I start poking at the code. I'm not sure how to break out of this

citrablue 7y ago
What does your pre-code design process look like? Might beef that up; its what has helped me quite a bit.
mandeepj 7y ago
> However at work, I often find that I feel like I can't write unit tests before starting code because I just don't know how it's going to get built until I start poking at the code. I'm not sure how to break out of this You'd start with shallow functions and quality asserts. Initially, you'd have broken tests, you have to write code to fix them, and that's your TDD.
- tcbasche 7y ago
  This is definitely the best way. Start with the how you want everything to look and make your code match your expectation.
  - quii 7y ago
    Hello, I wrote learn go with tests! Your comment is exactly what I try to get across in the book but it's not always easy. If you cant decide how you want something to look (as that's not always easy) just take a punt on something. Make sure it's a small decision and make something useful. Sure you might have to change it, but at least you'll be basing that on some real feedback.
    - fjp 7y ago
      Hi, thank you for writing the book! Great introduction to Go. One thing I was uncomfortable with about TDD is the step to "just write enough to make the test pass". The danger seems to be when you have to walk away from some code and you or whoever picks up your code doesn't know what you were up to. In a simple app and a few tests you could probably tell, but the larger an application gets, the less you can put effort into finding out "this test works because the application works how it should" or "this test works because someone wrote just enough code and hardcoded some value somewhere in order to make the test pass". It seems "safer" to write tests that are going to stay broken until every little corner of everything works properly, even though this is less iterative. As mentioned above I have little TDD experience, so maybe I'm missing something.
      - quii 7y ago
        The point of "just writing enough to make the test pass" is to get you to the point where you have working software (proven by the test, even if the code is "bad") This is the _only_ point where you can safely refactor, if your tests are failing how do you know you haven't broken something? So long as you keep things "green" you know you're ok > The danger seems to be when you have to walk away from some code and you or whoever picks up your code doesn't know what you were up to. Just don't do this. You're not "done" with the TDD cycle until you make it pass and have refactored. I reflect this in my git usage too, roughly it goes - Write a test -> Make it pass -> git commit -am "made it do something" -> refactor -> run tests (if i get in a mess, revert back to safety and try again) -> git add . -> git commit --amend --no-edit > It seems "safer" to write tests that are going to stay broken until every little corner of everything works properly, even though this is less iterative. The problem with this is how do you safely refactor when you have potentially dozens of tests failing? A big point of this approach is it makes refactoring a continuous process and makes it easier because you have tests proving you haven't accidentally changed behaviour.
twh270 7y ago
I'm not even thinking about "how it's going to get built" when I write test-first. I'm just writing (test) code as a client that's calling an API. It just so happens that the API (method, or method + object) in question doesn't actually exist yet, so the first thing I do is let the IDE generate them so it compiles. Once the code compiles I go into the implementation and make it work. Now and then I realize during implementation that I need some additional parameter, but it's easy to add that.
- fjp 7y ago
  I guess to me: 1) Writing a test that calls an API and asserts that everything resulted correctly from it is more of an integration test in my opinion - in this case I can agree this can be written beforehand. 2. If I'm changing my tests as I write my code then it doesn't matter if I go test-code-test-code vs code-test-code-test. I have still changed my definition of "correct" on the fly based on something I found out as I implemented.

dmux 7y ago

How have you achieved a balance between too little and too much testing? I worked on a project that had a ton of tests, but they seemed to be "over fitted."

tcbasche 7y ago
The trick is to get something covered to the point where you could comfortable refactor the bejeezus out of it, and know that it's still working from a higher level. The test should be how you know the code works, and under any situation. That is, you don't need to test that inbuilt standard library stuff is working as expected (e.g does a string reverse) but rather, does the combination of possible inputs match your expectations?