3 ms·

This is a good example for a small scale isolated project with a small amount of complexity. If however you are writing an enterprise level, scalable applicatio

This is a good example for a small scale isolated project with a small amount of complexity. If however you are writing an enterprise level, scalable application, with many business objects and tons of complexity, things get way harder. For example: What do you do if your function has a call to a 3rd party webservice? You do a mock. What do you do if you have 37 levels of state that are dependent on the objects you are receiving from the mock? Create 37 different business objects and verify that the output for each is correct. This problem builds and gets bigger, harder, and more conceptually complex. So while it can be easy to get started, it is not by definition intrinsically easy. However, it is well worth every minute spent. It makes refactoring and building up much much easier. It also leads a bread crumb of clues to figure out what the code is doing. It leads to better code stability, and far less regression.

tonyarkles 13y ago
I'm not criticizing your comment, just adding a little bit to it. You're totally right, there's a lot of complexity when you're testing complex features in a huge app. Buuuuut, a huge complex app is probably not the right place to try learning any new technology. Do a few small things first, prototype something out, test it along the way. Then maybe something a little more complicated. Slowly expand your horizon of uncertainty. That way you only need to focus on learning one thing at a time. The assert() call that OP suggested is exactly enough to start thinking about testing simple code; once you're doing well at it, you can start noticing repetition and opportunities for abstraction (and finding existing libraries that have these abstractions already done for you); then, you start doing testing on more complex code and start learning about mocks to facilitate testing there. Some people do really well in a "big bang" kind of learning environment, but I definitely don't. For me, learning works best given: a rough map of where I'm trying to get (even just a mind map that gives me things to look up when I get stuck), and an opportunity to master each piece before expanding onto new topics.
- tenpoundhammer 13y ago
  I agree.
trcollinson 13y ago
I was beginning to believe your comment would be like many others I have read in the past trying to justify why testing, and specifically TDD, should not be done in "real world" development. "Real systems are real complex, which means tests become complex, so we shouldn't waste our time with tests," and so on. But really you put it so well! Systems are complex and complicated, and tests are as well. But the effort we put into both have value in the end. Well said! I am constantly confused by this idea that because testing can get hard and complicated we should not do it. It's as if to say we should trust our untested code purely because the testing would be more complicated than not testing.

tonyarkles 13y ago

I'm not criticizing your comment, just adding a little bit to it. You're totally right, there's a lot of complexity when you're testing complex features in a huge app. Buuuuut, a huge complex app is probably not the right place to try learning any new technology. Do a few small things first, prototype something out, test it along the way. Then maybe something a little more complicated. Slowly expand your horizon of uncertainty. That way you only need to focus on learning one thing at a time. The assert() call that OP suggested is exactly enough to start thinking about testing simple code; once you're doing well at it, you can start noticing repetition and opportunities for abstraction (and finding existing libraries that have these abstractions already done for you); then, you start doing testing on more complex code and start learning about mocks to facilitate testing there. Some people do really well in a "big bang" kind of learning environment, but I definitely don't. For me, learning works best given: a rough map of where I'm trying to get (even just a mind map that gives me things to look up when I get stuck), and an opportunity to master each piece before expanding onto new topics.

tenpoundhammer 13y ago
I agree.

trcollinson 13y ago

I was beginning to believe your comment would be like many others I have read in the past trying to justify why testing, and specifically TDD, should not be done in "real world" development. "Real systems are real complex, which means tests become complex, so we shouldn't waste our time with tests," and so on. But really you put it so well! Systems are complex and complicated, and tests are as well. But the effort we put into both have value in the end. Well said! I am constantly confused by this idea that because testing can get hard and complicated we should not do it. It's as if to say we should trust our untested code purely because the testing would be more complicated than not testing.