Downloaded 40 times
Uploaded byRabble .
Finding the Middle Way of Testing
The document discusses various strategies and philosophies regarding software testing, including the importance of balance and the avoidance of testing too broadly or narrowly. It emphasizes the need for efficient testing practices, such as making tests fast and focusing on relevant areas to improve effectiveness. Several links to related resources on testing methods are provided throughout.
More Related Content
Similar to Finding the Middle Way of Testing
Finding the Middle Way of Testing
- 1. Testing Finding the MiddlePath source: http://flic.kr/p/6v82qN
- 2. The Flickr Way source: http://flic.kr/p/6MQYyj
- 3. The QA Way source: http://flic.kr/p/tvUHq
- 4. Test Everything Way source: http://flic.kr/p/7kKDuo
- 5. TATFT source: http://flic.kr/p/7kKDuo
- 6. Test All TheFucking Time source: http://flic.kr/p/7kKDuo
- 7. Overloaded With Tests source: http://flic.kr/p/GNhm3
- 8. Balance source: http://flic.kr/p/3enph8
- 9. Finding The Way source: http://flic.kr/p/5tZaUe
- 10. On Rails source: http://flic.kr/p/4WR1F9
- 11. Test All AtOnce source: http://flic.kr/p/7ZSbRQ
- 12. Don’t Test ToNarrowly source: http://flic.kr/p/6Zeo1V
- 13. Don’t Test ToBroadly source: http://flic.kr/p/7azreS
- 14. Testing What Is AlreadyTested source: http://flic.kr/p/3c89jn
- 15.
- 16. Cucumber source: http://flic.kr/p/5aZYkP
- 17. What You ShouldDo source: http://flic.kr/p/7qQZni
- 18. Integration source: http://flic.kr/p/kZtKo
- 19. Test The Bugs source: http://flic.kr/p/JAE3v
- 20. Refactoring source: http://flic.kr/p/88X9DY
- 21. Test Then Change source: http://flic.kr/p/aCDk7
- 22. Mocky Stubbly Things source: http://flic.kr/p/6Q6en
- 23. Make Tests Fast source: http://flic.kr/p/5tZaUe
- 24. Make Tests Fast TESTING TESTING! source: http://flic.kr/p/5tZaUe
- 25. Fixtures light fixture? source: http://flic.kr/p/5tZaUe
- 26. Data For Tests source: http://flic.kr/p/5tZaUe
- 27. true is notfalse source: http://flic.kr/p/5tZaUe
- 28. Tests Aren’t DRY source: http://flic.kr/p/5tZaUe
- 29. They’re Damp source: http://flic.kr/p/5tZaUe
- 30. Atomic source: http://flic.kr/p/5tZaUe
- 31. Atomic Failure source: http://flic.kr/p/5tZaUe
- 32. Outside In source: http://flic.kr/p/4KgEv
- 33. Self Contained source: http://flic.kr/p/5ZFbHE
- 34. Red Green source: http://flic.kr/p/5tZaUe
- 35. That’s My MiddlePath @rabble - cuboxsa.com source: http://flic.kr/p/6v82qN
Editor's Notes
- #2 I’ve wanted to do this talk for a while. I’ve given a bunch of talks on the mechanics of testing. But i feel like there is something missing. We need to talk more about what to test and what not to test. There is a kind of macho, who can test the We need a balance
- #3 One way of thinking of testing is to not do them, but to release often, quickly, write code with feature flags. I like to call this the flickr way, it works. It’s very similar to how facebook works really. Lots of small iterations. No tests, in code, you’ve got users for that! If the space between releases is really short, this model works.
- #4 http://flic.kr/p/tvUHq
- #5 The other direction is testing everything. You want it to be like this. Rushing along, everything is a blur as you race through development. This is called the TATFT method of software development. http://flic.kr/p/7kKDuo
- #6 This is the ‘test all the fucking time’ method of software development. It’s appealing because it’s hard core. Alpha male, Test First, Test Always style.
- #7 This is the ‘test all the fucking time’ method of software development. It’s appealing because it’s hard core. Alpha male, Test First, Test Always style.
- #8 But if done to extreme, without regard to utility, you get this. Burdened down by your tests. http://flic.kr/p/GNhm3
- #9 Sometimes we need to find balance between these ways. Testing is a technique we use to make better software.
- #10 So the question is then what’s the middle way. What rules should we use to decide what should and shouldn’t be tested. I’m going to go through a bunch of best and worst practices. My rules of thumb for the way of testing.
- #11 n ways to find the middle way in testing. What to test, what not to test, and when to know the difference. http://flic.kr/p/8kAmwf
- #12 I do rails development, the examples come from rails. But the point is try and extract ideas which are useful in many technology stacks.
- #13 The worse of the bad testing techniques is to go from no tests to spending weeks just writing tests. To catch up! http://flic.kr/p/7ZSbRQ
- #14 It’s important not to test to little, to be to focused on the details. You end up testing the implementation. Tests fail, but not because the software as a whole is broken. The simple, Assert 2, 1+1. It’s not interesting. http://flic.kr/p/6Zeo1V
- #15 Just as testing the details of an implementation, is bad, testing to broadly also can fail for two reasons. First is time. Testing is a tool for debugging. Debugging is what we are really doing most of the time when we say we’re programming. http://flic.kr/p/7azreS
- #16 One classic problem is when people start writing tests is that they are testing their use of somebody else’s library. Presumably that library should have tests itself, or if it doesn’t has at least a stable API. Treat it as a black box. http://flic.kr/p/3c89jn
- #17 One example in Rails is to do tests that confirm Active Record is working correctly. That a has_many association can be created and deleted.
- #18 I know there was just a talk about Gherkin, the extension of cucumber to make it work in multiple human languages. But i think you should just say no to Cucumber. Clients don’t want to write them. More to the point they can’t do them well. It’s a fascinating exercise, but cucumber stories do not translate in to good code. It’s bulky, nobody reads the stories, code when it fails is easier to understand. http://flic.kr/p/5aZYkP
- #19 http://flic.kr/p/7qQZni
- #20 Even though natural language tests like cucumber are, in my humble opinion a disaster, integration tests are a great idea. They’re code, they are ways of dealing with our web apps in a way similar to real use, but simulated. We’re mocking the real browser, and replacing it with something more useful for testing. http://flic.kr/p/kZtKo
- #21 This is what you should do. Test the bugs. Write tests when things break. What you should do is manually try and reproduce a bug. Then once you can ‘see’ it, then you write the test. Then with the test, you can fix it. This is the way to do it. Don’t do that sprint thing. http://flic.kr/p/JAE3v
- #23 When you go in an refactor, then is vital. Really this is the only time it makes sense to spend any time writing just tests. http://flic.kr/p/88X9DY
- #24 So when you’re refactoring, as opposed to updating, then you need tests. Because by definition, refactoring, is to change the implementation without changing the functionality. So you need a test to confirm the functionality is the same. http://flic.kr/p/aCDk7
- #25 The mocky stubbly things. Taking functionality out and replacing it with fakes. There be dragons here. On the one hand, if you have the full system, it’s slow to test. Things like networks, payment processing gateways, they aren’t things you want to hit when http://flic.kr/p/6Q6en
- #26 Show XKCD comic of compiling.... Testing is the new compiling. Perhaps we needed the cognitive space. A break in our work, and so in interpreted languages we started writing tests, to fill the gap which used to be created by compiling.
- #27 Show XKCD comic of compiling.... Testing is the new compiling. Perhaps we needed the cognitive space. A break in our work, and so in interpreted languages we started writing tests, to fill the gap which used to be created by compiling.
- #28 http://flic.kr/p/4heE23
- #29 http://flic.kr/p/55d56F
- #30 One lesson from the BDD experience is that you assertions must make sense. Think of writing the tests so when they fail, the test name makes sense, and the failure is directed. http://flic.kr/p/4Jrqs1
- #31 Tests are different from application code. It’s ok to repeat yourself. Some. http://flic.kr/p/gLUeh
- #32 The tests should be damp. As in, repeat yourself some. Because each test is of a variation of functionality, it requires some repetition. Not DRY, but damp as it were. http://flic.kr/p/4qBKRw
- #33 Your tests should be atomic. Each test has the same environment. This means your fixtures need to work well. If one test has an effect on another, then you’re in for a world for hurt. You know what happens when you start smashing volatile atoms together, right? http://flic.kr/p/7Gssw1
- #34 If you fail to keep your tests separate from each other, things fall apart http://en.wikipedia.org/wiki/Nuclear_explosion
- #35 I strongly agree with what Trotter said in the previous talk. Outside In. Finding the sweet spot, outside of your application, outside of the implementation, which you can test.
- #36 Similar to the atomic thing. You want your tests to be self contained. A single activity or thing. The tricky part here is to keep each test self contained, a bit of functionality, a unit as it were, but not so focused as to be a sub-unit. http://flic.kr/p/5ZFbHE
- #37 Easily be able to see what works and what doesn’t, clear red green results. If you’ve got one of those grahpical IDE things, then use that. The idea is you have to easily, automatically, know what works. So, it’s code, look to see if worked, code, see if it worked, code, see if it worked. That is the old school model of software development. http://flic.kr/p/7vVAJW
- #38 That’s my middle path, there is no one path. But i think we need to start calling out what we want, what we do, what we shouldn’t do in testing. While there may be more than one way to do it, all the ways aren’t the same, some work, some don’t.