Sometimes logging of an application's events is the only debugging method. The logging method's disadvantage is the large size of the code which you have to write manually to save the whole necessary information. The article touches upon the method allowing you to build a system of automatic logging of C/C++ code.
Building security into software is harder than it should be. This article explores a way to align application security practices with other software development best practices in order to make building security in easier to manage and more cost effective. In particular, this article looks at combining continuous integration (CI) with security testing and secure static code analysis.
Understanding combinations and permutations is a fundamental skill in software testing. In this month’s Test Run column I show you how to work with combinations and permutations using code written in the new F# language.
This article examines the whys and wherefores of continuous integration, and examines two of the leading (open source) tools for providing this service: Draco.NET and CruiseControl.NET. You will see how to get each up and running, and compare their strengths and weaknesses to determine when each is a better fit for your organization.
Agile development is the future of modern software engineering. Companies that have implemented it successfully have seen great improvements in their software—both in cost, stability, and in the utility of the software itself. However, some companies have struggled, finding it difficult to adapt their processes and culture to work in an Agile environment. One of the areas that best highlights the cultural shifts required to become an Agile organization is Continuous Integration (CI).
Today, we will have a look at another great feature of xdebug - creating code coverage statistics. Code coverage statistics show how many times each line of the code has been executed. Conversely, they also show which lines of code have not been executed, which is in fact much more interesting.
Most Java unit tests consist of a Class Under Test (CUT), and possibly dependencies or collaborators. The CUT, dependencies and collaborators need to be created somewhere. Some people create each object using 'new' (vanilla construction), others use patterns such as Test Data Builders or Object Mother. Sometimes dependencies and collaborators are instances of concrete classes and sometimes it makes more sense to use Test Doubles. This entry is about the patterns I've found most helpful for creating objects within my tests.