<commit_before>Testing & dd-agent
==================

[![Build Status](https://travis-ci.org/DataDog/dd-agent.svg)](https://travis-ci.org/DataDog/dd-agent)

# Lint

Your code should always be clean when doing `rake lint`.
The pylint configuration is not really aggressive so you're most welcome to use your own pylint config or tools like pep8 or pyflakes (we plan to plug in more restrictive stuff about that to try to keep sane defaults in the codebase)

# Unit tests

They mainly concern the core of the Datadog agent:

* how metrics are handled/submitted/aggregated
* how we run checks, handle failures
* more generic testing on the agent behavior and resilience
* system-oriented checks (may be considered as integration tests..)

```
# Run the suite
rake ci:run
```

# Integration tests

They ensure that the agent is correctly talking to third party software which is necessary for most checks.

They are great because they mimic a real setup where someone would enable a check on a machine with this service running. Using mocks or pre-saved responses often hides corner-cases and are the source of lots of issues.

We run these tests by creating a build machine "flavor" (see Travis section), basically each flavor is defined by the third party software we install on this machine.

Most of the times `flavor == check_name`.

Each flavor is defined in `ci/flavor.rb`, and we set different steps for running the flavor build :

* **before_install** needs to be run before installation
* **install** installs the 3p software
* **before_script** generally setups the software and launch it in background
* **script** runs nosetests with a filter (see how to write tests)
* **cleanup** stops the software and remove unnecessary data (not running on Travis, because the buildboxes are disposable)
* **before_cache** is run on Travis to delete logs files, configuration files, ... before caching
* **cache** tars and uploads the cache to S3

Your test cases must be written in `tests/test_flavor.py` and they must use the nose `attr` decorator to be filtered by the flavors.
<commit_msg>Add some documentation about running individual unittests<commit_after>Testing & dd-agent
==================

[![Build Status](https://travis-ci.org/DataDog/dd-agent.svg)](https://travis-ci.org/DataDog/dd-agent)

# Lint

Your code should always be clean when doing `rake lint`.
The pylint configuration is not really aggressive so you're most welcome to use your own pylint config or tools like pep8 or pyflakes (we plan to plug in more restrictive stuff about that to try to keep sane defaults in the codebase)

# Unit tests

They mainly concern the core of the Datadog agent:

* how metrics are handled/submitted/aggregated
* how we run checks, handle failures
* more generic testing on the agent behavior and resilience
* system-oriented checks (may be considered as integration tests..)

```
# Run the suite
rake ci:run
```

To run individual tests using [nosetests](https://nose.readthedocs.org/en/latest/):
```
# Whole file
$ nosetests tests/checks/mock/test_system_swap.py
# Whole class
$ nosetests tests/checks/mock/test_system_swap.py:SystemSwapTestCase
# Single test case
$ nosetests tests/checks/mock/test_system_swap.py:SystemSwapTestCase.test_system_swap
```

# Integration tests

They ensure that the agent is correctly talking to third party software which is necessary for most checks.

They are great because they mimic a real setup where someone would enable a check on a machine with this service running. Using mocks or pre-saved responses often hides corner-cases and are the source of lots of issues.

We run these tests by creating a build machine "flavor" (see Travis section), basically each flavor is defined by the third party software we install on this machine.

Most of the times `flavor == check_name`.

Each flavor is defined in `ci/flavor.rb`, and we set different steps for running the flavor build :

* **before_install** needs to be run before installation
* **install** installs the 3p software
* **before_script** generally setups the software and launch it in background
* **script** runs nosetests with a filter (see how to write tests)
* **cleanup** stops the software and remove unnecessary data (not running on Travis, because the buildboxes are disposable)
* **before_cache** is run on Travis to delete logs files, configuration files, ... before caching
* **cache** tars and uploads the cache to S3

Your test cases must be written in `tests/test_flavor.py` and they must use the nose `attr` decorator to be filtered by the flavors.

{'fraction_non_alphanumeric': 0.07574430823117338, 'fraction_numerical': 0.0013134851138353765, 'mean_word_length': 4.675776397515528, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 5, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5063217', 'n_tokens_mistral': 1225, 'n_tokens_neox': 1169, 'n_words': 627}