This is Stuff

Writing tests for grunt plugin turned out to be less straightforward then expected. I needed to run multiple task configurations and wanted to invoke them all by typing grunt test in main directory.

Grunt normally exits after first task failure. That makes it impossible to store multiple failure scenarios inside the main project gruntfile. Running them from there would require the --force option, but grunt then ignores all warnings which is not optimal.

Cleaner solution is to have a bunch of gruntfiles in separate directory and invoke them all from the main project gruntfile. This post explains how to do that.

Rules add special handling around tests, test cases or test suites. They can do additional validations common for all tests in the class, concurrently run multiple test instances, set up resources before each test or test case and tear them down afterwards.

The rule gets complete control over what will done with the test method, test case or test suite it is applied to. Complete control means that the rule decides what to do before and after running it and how to deal with thrown exceptions.

Dynamic tests generation is useful when you need to run the same set of tests on many different input values or configurations. It can be achieved either using parametrized tests or using theories.

Theories are valuable when you have a bunch of data to be used as parameters and want to run tests on all their combinations. You get less control, but you do not have to write combining and iterating code by yourself. Basics about how theories work are explained on java code geeks (original at java advent calendar), so this post focus on parametrized tests.

Parametrized tests are better when you need to have good control over the input values, e.g. directory with files that are served as an input or a list of meaningful parameters combinations.

Travis-CI is hosted continuous integration server for Github projects. The continuous integration part is fairly standard: it runs unit tests and report results after each project change.

The hosting part is unusual: the service runs tests on their own infrastructure and provides access to test results. The user does not need his own hardware nor to install and run the server. All that is part of the service.

Any public repository hosted on Github can use Travis-CI for free. Private repositories have to pay and the Travis Pro version they get is a bit different from the regular one.

This post is mainly about the free version. First chapter describes what Travis-CI does. Second part contains few things about Travis-CI server, infrastructure and organization behind it. Mini review with our experiences is located in the last chapter.

We wanted to test some JPA code with as simple setup as possible. The plan was to use only Java and Maven, without an application server or other J2EE container.

Our JPA configuration needs two things to run successfully:

This post has two parts. First part shows how to use standalone JNDI and an embedded in-memory database in test. Remaining chapters explain how the solution works.

Js-test-driver is an open source JavaScript unit tests runner written in Java. The project was started at Google and is under active development. It is available under Apache License 2.0 license.

Js-test-driver is able to run from command line and reports results to the standard output. As a result, it is possible to fully automate JavaScript tests and run them on a continuous integration server.

Additionally, js-test-driver comes with IntelliJ IDEA plugin and Eclipse plugin. Of course, Eclipse plugin is compatible with Aptana Studio. If you use one of these IDEs, you can run tests directly from IDE and see progress and results in a view. It is very similar to java jUnit plugin.

We have decided to introduce testing for security vulnerabilities into web application development. Previous part introduced cross site scripting, our web application and expectations we have for this project.

In this part, we go through all penetration testing tools we could find. Our goal is to find a suitable open source scanner. We wrote mini review of each found tool and picked up two scanners we will use.

Cross site scripting (XSS) is second most popular type of attack on web application. It allows attackers to execute scripts in victim’s browser and perform almost any action on users behalf. For example, script may hijack sessions or redirect the user to malicious sites.

This type of attack is relatively easy to perform and difficult to protect against. There are numerous different attack vectors and attacker needs only some knowledge of web technologies (JavaScript, CSS, HTML) to perform any of them. Moreover, one vulnerable place is enough to make whole application vulnerable.

This series of posts introduces XSS testing to a fictional development team working on a web project. The introduction describes both cross site scripting and fictional project requirements.