When asking how and what you should test, start by thinking about what the goal of your project is. Once you understand your goal, select the tests that will help you achieve your goal. Different goals will definitely warrant using different testing patterns. If you start using a specific testing pattern and it hurts, you're probably using a pattern you don't need, or you've implemented the pattern incorrectly. Remember, we're all still figuring this out, so there's not really patterns that are right; just patterns that are right in a given context.In other words, we should write tests if it helps write better code. That's it. Yeah, writing tests will probably help you write code that you know works, but there sure are a lot of ways to test. So use whatever tools you can to produce something better, but always think and always be ready to learn and adapt.
I've always liked how the trades have the notion of taking decades to really learn your craft. First, you start by being an apprentice, where you learn on the job from someone who's right beside you working on the same job, but who's already been there many times before. After you've proven your mettle, you become a journeyman where you practice on your own, but you continue to learn because you're still under the watchful eye and guidance of a master craftsman. In order to become a master, though, you have to produce a masterpiece and only if that's good enough might you be recognized and elected to the guild by the other masters.
No, building software isn't that different, rather, shouldn't be that different from this. More often than not, known when and why is just as important as knowing what and how. Building good products really does involves more art than most of us would like to admit.
One thing is for sure: we'll spend the rest of our careers learning to do things better, to write better code, and to craft a better product.
0 comments:
Post a Comment