Most developers seem to agree that testing is good, but developers frequently disagree about how to test. In this article, I’ll break down some common misconceptions and hopefully teach you a few…
ClassMock is a framework that helps the creation of unit tests for components that use reflection or annotations. In this kind of classes, the behavior is dependent of the class structure. This way, each test case usually works with a different class created specifically for the test. With ClassMock is possible to define and generate classes in runtime, allowing a better test readability and logic sharing between tests.
For those of you who've got into it you'll know that test driven development is great. It gives you the confidence to change code safe in the knowledge that if something breaks you'll know about it. Except for those bits you don't know how to test. Until now XML has been one of them. Oh sure you can use "<stuff></stuff>".equals("<stuff></stuff>"); but is that really gonna work when some joker decides to output a <stuff/>? -- damned right it's not ;-)
I googled test patterns in Go, then I invoked the Spirits of the Core Library. As soon as I realised where to look at, I finally saw a sign. It was Brad Fitzpatrick.
I did a talk at TestBash Germany last week that sparked lots of positive response, but also some critique. Critique is fair: It was a 30 minute inspirational talk in which I wanted to explain why Immanuel Kant’s work “Critique of Pure Reason” matters to testers. Quite a few people found me afterwards, asked me…
Abbot helps you test your Java UI. It comprises Abbot, which lets you programmatically drive UI components, and Costello (built on Abbot) which allows you to easily launch, explore and control an application. The framework may be used with both scripts and compiled code.
AceUnit (Advanced C and Embedded Unit) ist ein komfortables Framework für Unit-Tests von C-Code. AceUnit orientiert sich am Stil von JUnit 4.x und ist einfach, modular und flexibel. AceUnit kann in Umgebungen mit geringen Ressourcen verwendet werden, beispielsweise in der Entwicklung eingebetteter Systeme.
There are a number of open-source unit testing tools available. So why another one?
Well, this one addresses a specific need - an easy way to test XML-based servers. If you have a server that communicates with clients via XML messages, you can end up putting a lot of effort into using one of the unit-testing frameworks to test all the messages. Just think of all the code needed to set up communications, construct messages, and verify responses.
A simple alternative is to document XML messages and expected responses, without having to write any code. Let XmlMessageTest send each XML message to the server, verify returned messages against expected results, and produce a simple report of test results.
XmlMessageTest is written in Java and should be able to run any Java-enabled platform. It's been tested on Windows XP and Linux. It can be easily integrated into your build process.
This short guide is intended to catch you up with the most important reasoning, terms, tools, and approaches to JavaScript testing. It combines information from many great recently written articles…
Whoever reads and understands this guide, can safely assume they know the big picture of the state of JavaScript testing in the web development community for 2018.
This guide is intended to catch you up with the state of JavaScript testing in 2019. It combines information from the best recent articles, and our own experience at Welldone Software Solutions.
AOP makes it easier than it's ever been to write tests specific to your application's crosscutting concerns. Find out why and how to do it, as Nicholas Lesiecki introduces you to the benefits of testing aspect-oriented code and presents a catalog of patte
A picture's worth a 1000 tests.
Unit testing asserts can be difficult to use. Approval tests simplify this by taking a snapshot of the results, and confirming that they have not changed.
The project specification can be defined in word processor format as you would normally. By adding some special items, such as titled bulleted lists and highlighted text items, both a test suite and glossary can be written right into the spec. The Arbiter server will parse these documents and run the tests, reporting the results into the documents themselves. This allows the client to see project process.
For many years we've been using statically typed languages for the safety they offer. But now, as we all gradually adopt Test Driven Development, are we going to find that safety redundant? Will we therefore decide that the flexibility of dynamically typed languages is desirable?
AtUnit minimizes boilerplate code in unit tests and guides test development by enforcing good practices.
* mark exactly one field with @Unit to indicate the object under test.
* mark fields with @Mock or @Stub to obtain mock objects
* inject your tests, and your test subjects, using your favorite IoC container
Mock Objects Integration
AtUnit integrates with JMock or EasyMock to provide mock objects:
* obtain a JMock context simply by declaring a field
* annotate fields with @Mock to obtain JMock or EasyMock mock objects
* annotate fields with @Stub to obtain a JMock or EasyMock stub object
... or you can use your own mock objects plug-in with two easy steps:
* implement the MockFramework interface
* annotate your tests with @MockFrameworkClass(MyMockFramework.class)
Container Integration
AtUnit integrates with Guice or Spring to take all of the work out of dependency-injected tests.
With Guice:
* never see the Injector, never write bootstrapping boilerplate!
* @Inject test class fields without even defining a Module
* declaratively obtain mock objects with @Inject @Mock
* if you need more binding flexibility, simply have your test class implement Module
With Spring:
* annotate fields with @Bean to get them from the Spring context
* fields annotated with @Bean which do not appear in your Spring context are added to it automatically! (This includes @Mock and @Stub fields.)
* AtUnit looks for a Spring XML file with the same name as your test, or you can specify the location yourself with @Context("filename")
* Most of the time, you don't even need a Spring XML file!
You can easily plug in other containers in two steps:
* implement the Container interface
* annotate your tests with @ContainerClass(MyContainer.class)
AutAT
* is an open source Eclipse plugin,
* makes test driven development of web applications easier,
* contains a rich graphical editor for specifying how web-sites should function,
* is written using the Eclipse Graphical Editing Framework (GEF),
* converts a visual representation of web tests into executable tests, and
* executes the tests and gives you direct feedback.
With so many Continuous Integration (CI) servers to choose from, it can be difficult to decide which one is right for you. In the second article of the series Automation for the people, development automation expert Paul Duvall looks at a handful of open source CI servers, including Continuum, CruiseControl, and Luntbuild, using a consistent evaluation criteria and illustrative examples.
Feedback is vital for the practice of Continuous Integration (CI) -- in fact, it's the life blood of a CI system. Rapid feedback enables speedy responses to build events that require attention. Without feedback mediums like e-mail or RSS, builds in a broken state have the tendency to stay broken, which defeats the purpose of CI in the first place! In this installment of Automation for the people, automation expert Paul Duvall examines various feedback mechanisms that you can incorporate into CI systems.
When starting new projects, most of us plan to review code before actually releasing it into production; however, when delivery schedules supersede other factors, reviews tend to be the first practice thrown out. What if you were able to perform a portion of these reviews automatically? In this first article of the new series Automation for the people, development automation expert Paul Duvall begins with a look at how automated inspectors like CheckStyle, JavaNCSS, and CPD enhance the development process and when you should use them.
Nice article on IBM deveWorks: Ready to step up to the plate and hit a home run with your developer testing activities? In this installment of Automation for the people, development automation expert Paul Duvall covers some of the various types of automated developer tests you can run with every source code change. Paul provides examples of Selenium, DbUnit, and JUnitPerf tests that can help you discover application problems early -- that is, if they're run often.
What if you were able to discover potential problems in your code prior to building it? Interestingly enough, there are Eclipse plugins for tools such as JDepend and CheckStyle that can help you discover problems before they are manifested in software. In this installment of Automation for the people, automation expert Paul Duvall provides examples of installing, configuring, and using these static analysis plugins in Eclipse so that you can prevent problems early in the development life cycle.
How much time do you spend maintaining project build scripts? Probably much more than you'd expect or would like to admit. It doesn't have to be such a painful experience. Development automation expert Paul Duvall uses this installment of Automation for the people to demonstrate how to improve a number of common build practices that prevent teams from creating consistent, repeatable, and maintainable builds.
Fitnesse for Eclipse Plugin
Add Fit and Fitnesse support to your Eclipse tooling environment!
The FitNesse for Eclipse Plugin enables developers to more easily use the FitNesse and Fit frameworks from within the Eclipse environment.
Checklists, Important Considerations for Test Automation, Test Plan Sample & FAQ, Classification of Errors by Severity, What is Software Testing?, Load & Stress Testing of Websites, Outsourced Testing, ...
I first used Behaviour-Driven Development in a relatively disciplined way when writing Walrus. BDD is an incredible safety net for a beginner (Walrus was my first ever real Ruby project; previously I had only written 10-line scripts). It allows you to ens
Summary Eclipse offers the possibility to build plug-ins automatically outside the Eclipse IDE, which is called "headless build". Eclipse itself is built headless and since Eclipse is an assembly of plug-ins, this feature is also available for any other p
Bunny the Fuzzer dient zum Testen von C-Programmen. Es macht einen Trace des Programm-Ablaufs mit verschiedenen Eingaben und Parametern und überwacht Änderungen im Funktions-Aufrufspfad, den Aufruf-Parametern und Rückgabewerten.
Burp Proxy is an intercepting proxy server for security testing of web applications. It operates as a man-in-the-middle between your browser and the target application
Canoo WebTest is a free open source tool for automated testing of web applications.
It calls web pages and verifies results, giving comprehensive reports on success and failure. The White Paper provides an overview of the features and the design rationale. Detailed information is provided in the Manual Overview as well as the Install and Troubleshooting guides.
This is the homepage of the Code Analysis Plugin (CAP).
CAP is a plugin for the eclipse platform and analysis the dependencies of your Java project. It opens a own perspective and displays the results in an clear way using different diagrams.
"Create effective, grounded, timely materials to support the teaching and self-study of software testing, software reliability, and quality-related software metrics."
Selenium is an open source automation tool and definitely a great JavaScript automated testing framework which supports all operating systems and browsers such…
Cobertura is a free Java tool that calculates the percentage of code accessed by tests. It can be used to identify which parts of your Java program are lacking test coverage. It is based on jcoverage.
Software developers frequently encounter failures that occur only as the result of an interaction between two components. Failure triggering fault interactionsTesters often use pairwise testing – all pairs of parameter values – to detect such interactions. Combinatorial testing beyond pairwise is rarely used because good algorithms for higher strength combinations (e.g., 4-way or more) have not been available, but empirical evidence shows that some errors are triggered only by the interaction of three, four, or more parameters (see graph). These results have important implications for testing. If all faults in a system can be triggered by a combination of n or fewer parameters, then testing all n-way combinations of parameters can provide high confidence that nearly all faults have been discovered. We are producing methods and tools to generate tests for all n-way combinations of parameter values, using improved combinatorial testing algorithms for constructing covering arrays, and automated generation of test oracles using model checking.
As a certification company, CL enables companies of all sizes to have their products tested for potential inclusion in its list of Approved Quality products and bear the CL Seal. CL has tested more than 1,800 products, representing over 350 different bran
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.
S. Tan, D. Marinov, L. Tan, and G. Leavens. Software Testing, Verification and Validation (ICST), 2012 IEEE Fifth International Conference on, page 260-269. (April 2012)
S. Vegas, and V. Basili. Empirical Software Engineering, 10 (4):
437-466(2005)MR: Versucht die Antwort auf die Frage zu erleichtern: Wie soll indentifiziert werden, welches Testkriteria passen am besten zu meinem Testselektionsproblem?
Bei IST-SPL könnte es zur Begründung des eingesetzten Überdeckungskriteriums herangezogen werden..
M. Smucker, J. Allan, and B. Carterette. CIKM '07: Proceedings of the sixteenth ACM conference on Conference on information and knowledge management, page 623--632. New York, NY, USA, ACM, (2007)
S. Lauterburg, M. Dotta, D. Marinov, and G. Agha. 2009 IEEE/ACM International Conference on Automated Software Engineering, page 468--479. (November 2009)
E. Uzuncaova, D. Garcia, S. Khurshid, and D. Batory. ESEC-FSE '07: Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering, page 525--528. New York, NY, USA, ACM, (2007)ST: Die Spezifikation der Produktlinie liegt in einer formalen Beschreibung vor (LTL)
Es wird ein Modelchecking-Verfahren durchgefuehrt um zu beweisen, dass die Spezifikation gilt.
Fazit: Keine explizite Ableitung von Testdaten, die Spezifikation muss formal vorliegen.
MR: Anhand von formalen Alloy-Spezifikationen von Invarianten und Constraints kann der Alloy Analyzer (SAT solver) automatisch alle passenden Testdaten generieren.
Nachteile: Die erwarteten Ergebnisse werden nicht betrachtet (oder?). Die Spezifikation wird als Annotationen in den Code eingebracht (hier als moderner Ansatz angesehen ähnlich JML). An der Wiederverwendung wird erst gearbeitet..
A. Neto, R. Subramanyan, M. Vieira, and G. Travassos. WEASELTech '07: Proceedings of the 1st ACM international workshop on Empirical assessment of software engineering languages and technologies, page 31--36. New York, NY, USA, ACM, (2007)