There are multiple frameworks available for unit testing, and for any type of programming language. For Java developers, JUnit and TestNG are the most widely used. These frameworks are siblings and have the same test roots, and the debate over which is better is complex. Let’s look at how these two testing frameworks are different from each other, and which framework is better suited for your unit testing.
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.
Technical debt is an inevitable side effect of legacy code. Some code can (and should) be pruned, but institutional memory fades—what if there's a reason certain lines were included that may not be immediately obvious? Done right, unit tests can serve as documentation. Later on, these tests can illuminate what the developer was thinking when they created the code.
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.
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.
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.