by krptos on 1/2/17, 1:12 PM with 4 comments
I’ve read a lot about the importance of tests. You can assume I have a very abstract idea of topics like TDD, testable code, design for testability & the importance of tests in an evolving codebase.
But, I’m still very much deprived of motivations to actually spend time, writing tests.
#1. A lot of it is just procrastination, because I’ve never written any useful tests before & it feels like I need to know a lot more, for writing any useful tests.
#2. When I hold myself & sit down for writing tests, this is my thought sequence.
”The fake data that I’m going to pass as input for this function, is a static, dead, useless, hardcoded json.”
“For any useful feedback from the tests, I need to be feeding in fake data, that vary wildly and also it should look closely like real world, live, production data.”
“And I have to test the same function multiple times, with multiple types of fake data (dirty testing and such)”
“And the module I’m gonna write tests for has like, 148 functions!”
“And I have to mock this long list of interfaces & external calls”
“Jeez, that’s a lot of work!”
“Continue with #1”
I’m convinced that I have to change my perspective entirely, to overcome the procrastination.
Developers who’ve made the transition: How did you make it? What tricks can get me change my perspective? Advice please.
by cauterized on 1/2/17, 6:07 PM
Things that helped me make the adjustment:
- a good test harness that made writing and running tests relatively effortless - working for a few months on a team that used a methodology that wasn't strictly TDD but had a rule that pull requests would not be accepted without test coverage. (If your own team doesn't have this requirement, you may be able to find an open source project to contribute to that does.) - Working for a different few months on a codebase that was already well tested and thus a) already had the tooling necessary to make writing tests easy, and b) contained plenty of examples of sensible tests.
by al2o3cr on 1/2/17, 1:59 PM
* Consider: when you make a change, how do you verify that it worked?
* Write a test that does THAT and verifies the result. Don't stress out about DRYing out setup yet, write a test that WORKS first.
* Repeat. You will start to spot places where you can apply patterns like factories etc.
* The tests you write this way will pretty much be "integration tests", with all the baggage that carries (brittle, slow, heavy). You'll want to keep an eye out for seams where you can add more focused testing - for instance, can you isolate the part that needs to be tested with "multiple types of fake data" and test the output of that?
You may also want to try this out on a side project first; adding testing an existing codebase that doesn't have any is pretty much "hard mode".
I'd also recommend checking out talks on testing from Justin Searls (@searls).
by therealgimli on 1/2/17, 1:31 PM
My internal motivation for writing tests came from doing a lot of parallel/distributed computing. I had to write tests just so I could know what the heck was going on in my data transformations. I couldn't run my code on the full dataset while developing but with tests and small subsets of data I could develop with more confidence that my code would run efficiently and correctly on the full size set.
Though it took some time to really sink in, the end result was that I began to write code naturally that in addition to being easier to write tests for was clearer and more easily understood by colleagues or even my future self.
by itamarst on 1/3/17, 2:07 AM
2. Only test public interfaces
3. Only test things you want to be stable.
4. Most code has two parts, purely functional calculation and calls to outside world. Depending on where tricky bits are, focus on first part.
5. If testing is hard, cheat. Big picture covers-everything test. Then once you have some coverage you can refactor and see if you can make code more testable.
More ideas on what to do when testing is a pain: https://codewithoutrules.com/2016/02/21/painfultesting/