The test pyramid is a great model for designing your test portfolio. However, the bottom tends to fall out when you shift from progression testing to regression testing. The tests start failing, eroding the number of working unit tests at the base of your pyramid. If you don't have the development resources required for continuous unit test maintenance, there are still things you can do.
Writing changeable code makes it easier and more cost-effective to add features to existing software. Writing changeable code doesn’t take longer, but it does require paying attention to certain things when building a system. It's important to have a good suite of unit tests that support refactoring code when needed, and test-driven development helps you create independently testable code.
Code can express what we want to accomplish, but it’s a little more difficult to express why we’re doing something in the first place. The people who maintain code are often not those who originally wrote it, so documenting why helps set a context and gives clues as to what the author was thinking when they came up with a particular design, making developers' jobs easier.
There are two distinct roles in many software projects that are involved with testing: developers and testers. Should they take the same approach to testing, or are there some principles that apply to only one of the roles? What should they do to coordinate their work? Danny Faught went through an exercise to compare and contrast and found that the questions he couldn't answer were as interesting as the questions he could answers.
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.
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.