4 ms·

One of my pet peeves when I was learning programming is that I couldn't find any books that would teach how to write tests in real world. There was that chicke

One of my pet peeves when I was learning programming is that I couldn't find any books that would teach how to write tests in real world. There was that chicken and egg problem then, when potential employers would skip my CV because I didn't have any TDD experience and I couldn't find anywhere how to learn this. Before I even learned that something like testing exist, I was so confident like "oh I could write something like that over the weekend, how come they needed months to do that?". Then my software would crash the first time someone other than me used it. Anyway - what I want to say that while this book sounds like a great idea, without showing TDD and how to write code so that it can be proven it works the way intended and that it can handle unhappy paths and edge cases, it won't teach someone trying to learn programming much and it doesn't actually stand over about million other books about programming that really just scratch the surface and don't show how to write production ready code. That's what is still missing on the market. It's almost like a well kept secret that only developers working at large corporations know. That skill was very very difficult to acquire.

bilekas 4y ago
While i have so many things i could say about your idea of what development means and the "only path" you seem to subscribe to. I think you're missing the point of the book. > it won't teach someone trying to learn programming much and it doesn't actually stand over about million other books about programming that really just scratch the surface and don't show how to write production ready code. It's not a book to teach people how to program, infact the author goes out of their way to mention only C and minor c++ has been used and that it may be beneficial for learning how to build out such a POC of redis, to DIY your own. This is not a book to hand over to an outsourcing company and expect production ready work. Nor was it described as such.
x86hacker1010 4y ago
I commented this above, but Distributed Services in Go does testing and low-level kafka-like implementation. It taught me so much, I'm probably going to reread at some point and implement in Rust.
Zvez 4y ago
I remember how tdd (together with scrum) was basically a religion in 'large corporations'. How a lot of people talked about 'the right way to do things'. Your comment made me smile nostalgically... But back to the topic. I'm pretty sure there are enough books about how to write tests. And more or less all engineers understand the value of testability and coverage (not necessary tdd!). At leas I wouldn't need a book for this. But books about building something closer to complex real world systems - that's a good stuff engineers would enjoy.
- robertlagrant 4y ago
  What would you say makes better software than TDD?
cormacrelf 4y ago
It’s right there in the name TDD. You write a test and then you change the code to make the test pass. There are no secrets, that’s all there is to it. If you can do that you can do TDD. That’s why everyone else is putting it on their CV and you aren’t: you think there’s something more to it. There isn’t. It’s a very basic technique. > how to write code so that it can be proven it works the way intended and that it can handle unhappy paths and edge cases That is not what TDD promises. All TDD does is ensure you have some tests at all, which is a good base on which to add more tests, so that when you find edge cases you can do more TDD, and TDD is a nice way to work. Nobody in history has come up with a way to make testing comprehensive. You can try quickcheck and fuzzing to generate lots and lots of test cases, but they are still sampling from the input space rather than covering it. You can cover the input space for a single 32-bit number input, but that’s about it. The only way to do better is to formally prove your software is correct using mathematical logic. TDD does not provide this and never will. You might have seen “100% test coverage”, but that claim is close to meaningless with respect to the range of possible inputs that your code is meant to handle. All it says is that every edge case that you did think of has a test that exercises it. A function consisting of “return 0” only will have 100% test coverage with a single test in the suite. Doesn’t mean it works. See SQLite, which still finds bugs despite 100% test coverage. What you seem to be looking for is someone to teach you how to think of edge cases. That’s a skill that can’t really be taught. Just have a go. When you find an edge case later that you didn’t think of, great, maybe you will think of similar ones next time.
dcuthbertson 4y ago
A long time ago I found the chicken and egg problem to be more general than TDD. It was more along the lines of, "how do you write a program when you don't have the code (subroutines, other functions) it needs to run?" Where do you start - at main() or say, opening a file that doesn't yet exist to read/write some data? It was always a struggle. Then I found Structure and Interpretation of Computer Programs (SICP)[0] and the video lectures from MIT[1]. I had an epiphany when Sussman talked about "wishful thinking" in video for lecture 1b[0] (around 48:00 in). The lesson was something along the lines of start naming functions that would do what you needed done, and write them later. Just pretend they exist and eventually bring them into existence. SICP has so many gems. It really made a difference for me. If applied to TDD, write a test that won't even compile because the function under test doesn't even exist. Then iterate by writing something that compiles, but will probably fail, and then improve it until the test passes. [0]: https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/index.html https://mitp-content-server.mit.edu/books/content/sectbyfn/b... [1]: https://ocw.mit.edu/courses/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video_galleries/video-lectures/ https://ocw.mit.edu/courses/6-001-structure-and-interpretati... [2]: https://www.youtube.com/watch?v=V_7mmwpgJHU&t=2s https://www.youtube.com/watch?v=V_7mmwpgJHU&t=2s Edit: How to Design Programs and How to Design Worlds are two other resources I enjoyed. I don't write programs in Lisp or Scheme anymore, but the experience of just running through the exercises in these and other books was enlightening.
- varispeed 4y ago
  Brilliant, thank you for sharing!

bilekas 4y ago

While i have so many things i could say about your idea of what development means and the "only path" you seem to subscribe to. I think you're missing the point of the book. > it won't teach someone trying to learn programming much and it doesn't actually stand over about million other books about programming that really just scratch the surface and don't show how to write production ready code. It's not a book to teach people how to program, infact the author goes out of their way to mention only C and minor c++ has been used and that it may be beneficial for learning how to build out such a POC of redis, to DIY your own. This is not a book to hand over to an outsourcing company and expect production ready work. Nor was it described as such.

x86hacker1010 4y ago

I commented this above, but Distributed Services in Go does testing and low-level kafka-like implementation. It taught me so much, I'm probably going to reread at some point and implement in Rust.

Zvez 4y ago

I remember how tdd (together with scrum) was basically a religion in 'large corporations'. How a lot of people talked about 'the right way to do things'. Your comment made me smile nostalgically... But back to the topic. I'm pretty sure there are enough books about how to write tests. And more or less all engineers understand the value of testability and coverage (not necessary tdd!). At leas I wouldn't need a book for this. But books about building something closer to complex real world systems - that's a good stuff engineers would enjoy.

robertlagrant 4y ago
What would you say makes better software than TDD?

cormacrelf 4y ago

It’s right there in the name TDD. You write a test and then you change the code to make the test pass. There are no secrets, that’s all there is to it. If you can do that you can do TDD. That’s why everyone else is putting it on their CV and you aren’t: you think there’s something more to it. There isn’t. It’s a very basic technique. > how to write code so that it can be proven it works the way intended and that it can handle unhappy paths and edge cases That is not what TDD promises. All TDD does is ensure you have some tests at all, which is a good base on which to add more tests, so that when you find edge cases you can do more TDD, and TDD is a nice way to work. Nobody in history has come up with a way to make testing comprehensive. You can try quickcheck and fuzzing to generate lots and lots of test cases, but they are still sampling from the input space rather than covering it. You can cover the input space for a single 32-bit number input, but that’s about it. The only way to do better is to formally prove your software is correct using mathematical logic. TDD does not provide this and never will. You might have seen “100% test coverage”, but that claim is close to meaningless with respect to the range of possible inputs that your code is meant to handle. All it says is that every edge case that you did think of has a test that exercises it. A function consisting of “return 0” only will have 100% test coverage with a single test in the suite. Doesn’t mean it works. See SQLite, which still finds bugs despite 100% test coverage. What you seem to be looking for is someone to teach you how to think of edge cases. That’s a skill that can’t really be taught. Just have a go. When you find an edge case later that you didn’t think of, great, maybe you will think of similar ones next time.

dcuthbertson 4y ago

A long time ago I found the chicken and egg problem to be more general than TDD. It was more along the lines of, "how do you write a program when you don't have the code (subroutines, other functions) it needs to run?" Where do you start - at main() or say, opening a file that doesn't yet exist to read/write some data? It was always a struggle. Then I found Structure and Interpretation of Computer Programs (SICP)[0] and the video lectures from MIT[1]. I had an epiphany when Sussman talked about "wishful thinking" in video for lecture 1b[0] (around 48:00 in). The lesson was something along the lines of start naming functions that would do what you needed done, and write them later. Just pretend they exist and eventually bring them into existence. SICP has so many gems. It really made a difference for me. If applied to TDD, write a test that won't even compile because the function under test doesn't even exist. Then iterate by writing something that compiles, but will probably fail, and then improve it until the test passes. [0]: https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/index.html https://mitp-content-server.mit.edu/books/content/sectbyfn/b... [1]: https://ocw.mit.edu/courses/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video_galleries/video-lectures/ https://ocw.mit.edu/courses/6-001-structure-and-interpretati... [2]: https://www.youtube.com/watch?v=V_7mmwpgJHU&t=2s https://www.youtube.com/watch?v=V_7mmwpgJHU&t=2s Edit: How to Design Programs and How to Design Worlds are two other resources I enjoyed. I don't write programs in Lisp or Scheme anymore, but the experience of just running through the exercises in these and other books was enlightening.

varispeed 4y ago
Brilliant, thank you for sharing!