Question: I'd like to build a classificator machine of items, creating rules and using weight. There could be no clear details to define an item, just the high score. 
An example. 

```
If item A has x part then A.set(Category.A, 5) //weigth 5 
If item A has y part then A.set(Category.B,3) //weigth 3 
If item A has z part then A.set(Category.B,2) //weigth 2 
... 

```

After all the rules executed, you have an score of each category, so finally item A is Category whatever. 

Is this possible using DROOLS? any example of this? 
Many thanks.

---

Adding more info as required:
I want to classify news (as example).

```
If NewsA has in title "won" then NewsA is likely SportNews as 20%
If NewsA is writen by MisterX then NewsA is likely InternationalNews as 60%
If NewsA has more than 2 times word "football" then NewsA is likely SportNews as 50%

```

So, one news like that:  

> 
> **Barcelona won yesterday**  
>  bla, bla, bla... football, bla,... football, bla, bla, bla ...football...  
>  *written by MisterX*
> 
> 
> 

This news will be classified as SportNews because 20+50 is more than 60 of InternationalNews category. I want to implement something like that in doors, with multiple rules and weight.  

Thanks again!

Answer: 
As soon as you said `I want to make sure that the tasks are in the proper order, and the business rules are correct within the process itself.` you stopped talking about unit tests and began talking about integration tests. 

Even though you are decoupling from the datastore and services you are testing *busines rules*. If your organization is anything like mine, business rules can (and often do) change. It is this volatile nature that makes it an integration test. 

The base rule I've used is "unit tests are modular, *independent* pieces of code not dependant upon external data sources. whereas integration tests are tests that *require* the use of external data sources, either mocked up or from production."

The art of Unit Testing, second edition lists Integration tests with the following definition: 

> 
> I consider integration tests as any tests that aren’t fast and consistent and that use one or more real dependencies of the units under test. For example, if the test uses the real system time, the real filesystem, or a real database, it has stepped into the realm of integration testing.
> 
> 
> 

and unit tests with the following (emphasis mine): 

> 
> A unit test is an automated piece of code that invokes the unit of work being tested, and then **checks some assumptions about a single end result of that unit.** A unit test is almost always written using a unit testing framework. It can be written easily and runs quickly. It’s trustworthy, readable, and maintainable. It’s consistent in its results as long as production code hasn't changed.
> 
> 
> 

Based upon the same book as above. A unit test :

* `Is an automated piece of code that invokes a different method and then checks some assumptions on the logical behaviour of that method or class.`
	+ This is true if you can reduce `ProcessA/B/C` into small chunks that can be tested independently of one another.
* `can be executed repeatedly by anyone on the development team.`
	+ If someone from your team requires values or a cheat sheet to refer to determine if the test passes or not, it is not a unit test.

Now based upon your edit it depends. Integration tests and unit tests can overlap and many other developers may have different ideas on to how they would label the tests. 

The answer to your question is to determine the best practice for you and your development team. If the consensus it's a unit test, then consider it as such. 

Unit and integration tests should *help* the process, not hinder it. Please don't let semantics get in the way of that.
Setting aside tools etc... **Unit test** is simply testing a specific piece of code and would typically be performed by the programmer.

Functional and Integration are typically performed by QA team:

**Functional Testing** is testing if the code does what it was intended to do.

**Integration Testing** is about testing code and measuring how it interacts with other modules/parts of the system.