How many times does something seem too obvious to check? Most of the time this normal human response is a handy shortcut. Your brain tries to save you time—but you can’t always trust it. If your code malfunctions, each of those "too obvious to check" thoughts will bias your thinking about what caused the malfunction. We have to commit up front, before our thinking crystalizes, that the code will have to prove to us that it is correct.
You may feel you don't have time to write unit tests, but you really don't have time not to. Steve Poling makes the case that writing tests first not only will yield better code, but will help you get that code working right sooner. Here's how using a test-first approach changes your thinking about coding, lets you see mistakes immediately, and helps you create more testable code.
If you think that test automation is mostly about executing tests, then you're missing out on a big opportunity. Or rather, you're missing a lot of small opportunities adding up to a big one. Consider this: stop thinking about test automation as merely executing automated tests, stop thinking about test automation as something you need expensive tools for, and start discovering automation you can implement in a couple of days and usually with extremely inexpensive tools or tools you already have available. In this week's column, Danny Faught and James Bach suggest taking a more Agile approach to test automation.
It seems like every week there's a new security disaster impacting millions of users worldwide. With the acceptance of mobile apps providing timely data at your fingertips, users are becoming very concerned about security. Philip gives you some impactful tips for developing apps that create trust with end-users.
Agile projects assume that test planning, test creation, and test execution take place throughout a project's lifecycle. So the need for unit testing (and especially automated unit testing) can't be ignored and should be considered as a key responsibility of the entire team—not just the software developers.
With all of the resources available these days—books, blogs, Webcasts, training,—that aid us in our design, are you one of those programmers who lacks the "olfactory gene" needed to detect refactoring odors in your code? Unit testing helps you refine your sense of smell and improve your code design.
Senior Consultant Byron Katz and Consultant Matthew Taylor of Coveros test an open-source timekeeping tool project that their team is working on. Technology stack: Kotlin, JVM, Intellij, Gradle Open source at https://github.com/7ep/r3z
Melissa Benua, director of engineering at mParticle, chats with TechWell community manager Owen Gotimer about the importance of whole team quality, how to get started using the test pyramid, and how developers can start writing testable code.
TechWell's Noel Wurst got the chance to sit down with Ole Lensmar, Chief Architect at SmartBear. Ole discussed the differences between unit and API testing, the importance of choosing the best testing methods, and the benefits of reusing test assets.
The agile revolution began more than a dozen years ago. It was started by a small band of rebels who had radical ideas, shared a common vision, and wanted to change the world by challenging the status quo. Where is that agile revolution today? Has it continued the vision of its founders?
Mock objects are simulated objects that mimic the behavior of real objects in controlled ways. Because many code modules interact with external entities-things like databases, networks, file systems, third-party frameworks, and even the clock-these entities often cause us big-time trouble during unit testing. These entities can slow down our unit tests, produce unpredictable results, and have dangerous side effects. The best unit tests are decoupled from these external entities. Rather than try to control the entities, you can create mock objects to simulate their functionality. With a tangible example in the form of a short play, Rob Myers introduces mock objects and provides a brief history of their "relatives"-stubs and fakes. Then, with an animated, nearly-worst-case example, Rob presents code he developed to "mock out" nasty dependencies and create safe, predictable unit tests.
Using an analogy to the building codes followed by architects and contractors in the construction of buildings, Rick Spiewak explores the fundamental principles for developing and delivering high quality, mission-critical systems. Just as buildings are constructed using different materials and techniques, we use a variety of languages, methodologies, and tools to develop software. Although there is no formal "building code" for software, software projects should consider-and judiciously apply-the recognized "best" practices of static analysis, automated unit testing, code re-use, and peer reviews. Rick takes you on a deep dive into each of these techniques where you'll learn about their advantages, disadvantages, costs, challenges, and more.