SmartBear
Cart
Login
Welcome back to SmartBear Software
Click the links below to login to your favorite tool or into your client services portal
SmartBear Forum
Register
Log in
Development
DevComplete
ALMComplete
AQtime Pro
Automated Build Studio
Testing & QA
TestComplete
TestExecute
TestRecorder
QAComplete
LoadCOmplete
Web Monitoring
AlertSite
Free Tools
QAPlanner
DevPlanner
Looking for a Free Trial?
Products
Products
For Development
Collaborator
Code Review & Document Review
ALMComplete
Lifecycle Management
AQtime Pro
Performance Profiling
Automated Build Studio
Software Release Management
SoapUI Pro
API Testing - SoapUI Pro
All Development
For Testing & QA
TestComplete
Automated Testing
QAComplete
Test Management
WebLoadUI Pro
Load Testing
AQtime Pro
Performance Profiling
LoadUI Pro
API Load Testing
All Testing & QA
For Web Monitoring
AlertSite
Website Monitoring
AlertSite API Monitoring
Free API Monitoring
AlertSite Insite
Internal Website Monitoring
Free Tools
AlertSite for API Monitoring
WebLoadUI
DéjàClick
AlertSite for Magento
Open Source Tools
SoapUI
LoadUI
Get the Free Tools
For Your Needs
Agile Testing
API Testing
Automated Testing
Code Review
Load Testing Tools
Test Management
Web Monitoring
Resources
Resources Overview
eBooks
Templates & Worksheets
Videos
Whitepapers
Support
Support when you need it
SmartBear technical representatives are always ready to help with your product needs.
Browse our support portal
Know what you're looking for?
Downloads
User Guides
How To Tutorials
Technical Articles
Screencasts/Videos
General support
Forums
Troubleshooter
FAQs
Product Versions
Community
About Us
Contact Us
Our Partners
Our Team
Our Customers
Careers
Awards
Our Speakers
Request a Speaker
News & Events
News Releases
Events
In the News
Webinars On-demand
Prior Events
Blog
Share
Home
›
Unit Tests
Unit Tests
SPEAKER 1: This is a fun one that one of our customers, maybe more than one, does. It's a little extreme, but it's fun. Their philosophy is, we're going to code review the unit tests and never code review the code. And the theory is that if the unit tests are complete enough but not over specified so that it's hard to make reasonable refactorings, reasonable changes, then, here comes the rock and roll quotes, it doesn't matter what the code looks like because it's automatically maintainable because unit tests are good. If the code's too slow, but we can fix that really with great confidence, if the code doesn't have enough commentary, ell, but it works, so we're willing to take that. Personally I think it's a little extreme to never look at the code, because human beings are, in fact, going to have to look at the code and there's no time like now to fix either obvious things, or just make sure it's understandable by another human being. But it certainly does save you some time, and it definitely gets you some very tangible value both in terms of correctness today and maintainability tomorrow to just look at the unit tests, and plus, unit test code reviews are fun because they're like a little treasure hunt. OK, you need to add these tests, or whatever. Or you can argue about whether some weird corner case ought to be this way or that way. So it's also kind of fun. But I feel like code review that's both unit tests and the code is, of course, more effective, and pretty fast still. Because when you look at code and unit tests, you will naturally do the unit test first, because if they're wrong, or if it's clearly a bug, then who cares what the code looks like, right? Clearly first it has to be correct. But then what's fun about that is if you've the unit tests are right, then when you do look at the code, you're not looking for correctness. Which is great, because that's annoying, and it's hard, and you're not that good at looking at correctness in code, right? Following if statements. You're not going to find a lot of subtle errors looking at the code without spending a ton of time. That's what the unit tests are good for. All those kind of corner cases. So it's actually pretty neat. It's pretty efficient to use unit tests to look at correctness, and then in the code, you're looking for those bigger concepts like scalability, or error handling, or whether it's just possible to read, possible to understand what's going on. There's enough of commentary, just enough commentary to understand that which is not encoded in the code itself. So I feel like it's still pretty efficient and valuable to look at both, but anyway, it's one way to save time.
