Psychology of Testing at Wealthfront
Berkeley: Test Driven Development in Angular
RTAC2010: All hands on testing
Just wanted to share my presentation from the RTAC 2010 conference.
Slides
Handout
<angular/>: A Radically Different Way of Building AJAX Apps
How JavaScript Works
Clean Code Talks – Unit Testing
Testing Design Skills – 1 What is Untestable
Testing Design Skills – 2 Ask for things
Testing Design Skills – 3 Global State
Testing Design Skills – 4 Inheritance
Testing Design Skills – 5 TDD
Demo
15 responses so far ↓
Other problems with Singleton - Bashar’s Blog // Mar 13, 2010 at 12:20 pm
[...] I could spent a few pages arguing and / or explaining those issues. Instead of that, I would recommend you to watch Miško Hevery’s presentations. [...]
I like your work and I learned a lot from it.
Do you have a link to the “Testing Services with Value Objects” presentation?
Shimi
@ Shimi,
sorry, i don’t have that one recorded
could you make another presentation on Testing Services with Value Objects :O
» Example project workflow using SWCs // Jun 26, 2010 at 8:01 am
[...] checkout those fantastic Mi?ko Hevery presentations. Mi?ko talks about why tests is so important, why beware of Singletons, how to use dependency [...]
» Example project workflow using SWCs // Jun 27, 2010 at 6:09 pm
[...] checkout those fantastic Miško Hevery presentations. Miško talks about why tests is so important, why beware of Singletons, how to use dependency [...]
Thanks for great presentations.
Talk, related to functional approach and avoiding ‘if’ statements really helped to order my clustered knowledge bas into a single, focused one.
One question about working with legacy applications: I have really evil Singleton of Singletons: it’s ResourceLocator, which is used application-wide to pull other Singletons (each one is totally untestable and out of my control: no interfaces, just plain classes, JNDI resources pulling in constructors, lots of static methods etc.) – I can’t mock them and/or substitute (because of JNDI in constructors). There’s no need to say, that dependent code is totally untestable. We can’t get rid of these proxies (it’s external systems proxies and we don’t own the codebase), but I really want to isolate all the new code from them. The only acceptable solution I found is to create separate interfaces, which will have same method signatures and use dynamic adapters, which will redirect all calls addressed from generated dynamic proxies to old Singletons. The only drawback: in case of any API changes we have to re-generate these interfaces to reflect the changes (it’s like relationship between Bean and Remote/Local interfaces in EJB). Any other possible solutions, how to isolate these proxies?
@Alex,
I think your solution is what I would have suggested as well. You need to put a layer of indirection between you and them. My only suggestion would be to not make the api match exactly what they give you but rather create an ideal API for yourself. That way your your code using these dependencies is simpler. Also if the external APIs change than the only things you have to change is the adapter and not all of the instances. You may have a hard time testing the adapters, but the rest of the system should be fine.
– misko
Hi Misko,
I’m thinking of using some of these slides, translating them (in french) and making a similar presentation in my company. What license are they under ? Are you OK with this ?
Thanks for your great website & presentations !
@Aurelien
I have not released the docs under any official license, but you are free to use/translate the slides, as long as you keep a link to the originals for attribution. Other then that, feel free to spread the word, and educate others.
– Misko
Wow.. these talks are really helpful. It really changes the way I think about coding. I think you should write a book on this subject with more real work examples. I know I would buy this book so are the rest of my teammates.
@Kevin,
the thought has crossed my mind, but it is a lot of work.
Extreme Enthusiasm » Blog Archive » How I remembered Object Thinking // Dec 13, 2011 at 2:58 pm
[...] OOP. I learned about the GOF patterns. I learned about the SOLID principles. I learned how to write testable code. I learned how to do TDD for the infrastructure. I learned how to test-drive Chicago style and [...]
Misko,
Great talks! At the end of your Clean Code talk on Global State and Singletons you make reference to some cards on what to look for in code reviews. Could you possibly make those available?
They are here: http://misko.hevery.com/code-reviewers-guide/
Leave a Comment