RE: Adopting mock framework (ex. Mockito) for unit tests

[Jason Man, CLSA]

As discussed, updated the PR with the change to put the mockito version at the 
parent POM and using it on the cassandra module.

https://github.com/apache/ignite/pull/3088

Thanks.

-Original Message-
From: Denis Magda [mailto:dma...@apache.org] 
Sent: Wednesday, January 17, 2018 9:55 AM
To: dev@ignite.apache.org; Igor Rudyak
Subject: Re: Adopting mock framework (ex. Mockito) for unit tests

Looks we came to a consensus. Jason, please change the PR the way you say

> I will change my PR to add the dependency at parent POM level and use it only 
> for my test in ignite-cassandra.

Igor should review it shortly.

—
Denis

> On Jan 16, 2018, at 5:33 PM, Jason Man, CLSA <jason@clsa.com> wrote:
> 
> Agree with Vladimir/Denis/Igor on using it for specific tests/components.
> 
> What I meant by 'adopt' is to be able use it to facilitate testing of Ignite 
> code somewhere.  It doesn’t mean we should change our overall testing 
> approach overnight and try to use it everywhere.
> 
> In the case of testing code that integrates 3rd party tools (Postgres, MySQL, 
> Cassandra), I think it definitely simplifies the test development effort as 
> well as the time it takes to run the tests.
> 
> @Alexey, I haven't explored using JMockit, but Mockito was just a very 
> popular mocking framework and widely used so it would be less of a learning 
> curve for most developers:
> https://trends.google.com/trends/explore?q=jmockit,mockito
> 
> I will change my PR to add the dependency at parent POM level and use it only 
> for my test in ignite-cassandra.
> 
> Jason
> 
> -Original Message-
> From: Denis Magda [mailto:dma...@apache.org]
> Sent: Wednesday, January 17, 2018 3:53 AM
> To: dev@ignite.apache.org
> Subject: Re: Adopting mock framework (ex. Mockito) for unit tests
> 
> Agree with Igor’s opinion. If it simplifies Cassandra integration testing 
> cycles and maintenance then we should go for it for *this* component only. No 
> need to push it to all the component we have.
> 
> —
> Denis
> 
>> On Jan 16, 2018, at 10:24 AM, Igor Rudyak <irud...@gmail.com> wrote:
>> 
>> It will be good to clarify what do you mean by adopt? Can't we just 
>> start using it as is for specific cases?
>> 
>> I understand that there are some cases which probably not the best 
>> scenario for Mockito. At the same time there are lot's of other cases 
>> (like in
>> IGNITE-6853 <https://issues.apache.org/jira/browse/IGNITE-6853>) when 
>> tests could be significantly simplified using mock framework.
>> 
>> May be it makes sense to introduce mock framework at the parent POM 
>> and then just reuse it at specific modules for the test cases where 
>> appropriate?
>> 
>> Igor
>> 
>> On Tue, Jan 16, 2018 at 4:27 AM, Vladimir Ozerov 
>> <voze...@gridgain.com>
>> wrote:
>> 
>>> Mocking is a good testing technique, but over years we failed to 
>>> adopt it in Ignite. The reason is high project complexity, when a 
>>> lot of components are interact with each other, and it is very hard 
>>> to extract clean interfaces out of it. We definitely could do better 
>>> with our OOP, but you should remember that good OOP comes at costs - 
>>> more code, more time, worse performance (due to lot's of various 
>>> wrappers). I think of it as a normal case based on my experience - I 
>>> worked with a lot of code bases (Postgres, MySQL, Cassandra, 
>>> Hazelcast, to name a few) - and none of them are clean enough to 
>>> adopt mocking easily. You hardly find clean code in performance-demanded 
>>> projects.
>>> 
>>> TDD is also controversial approach for complex projects. It works 
>>> good when you work on concrete specification of the task and know 
>>> the outcome in advance. But it doesn't work for Ignite - typically 
>>> we do not know outcomes of our activities in advance. Things could 
>>> change dramatically during developments, so TDD for us is waste of time.
>>> 
>>> On the other hand, today we are able to "mock" a lot of internal 
>>> components by hands to test various complex cases. E.g. one can 
>>> easily add his own IO manager to test message drops. You can do virtually 
>>> everything you need.
>>> 
>>> For this reason I doubt mocking is the right approach we should 
>>> think of for core development. But it may do great job for 
>>> integration with 3rd-party products.
>>> 
>>> Vladimir.
>>> 
>>> On Tue, Jan 16, 2018 at 1:34 PM, Alexey Kukushkin < 
>>> kukushkinale...@gmail.com
>&

Re: Adopting mock framework (ex. Mockito) for unit tests

[Denis Magda]

Looks we came to a consensus. Jason, please change the PR the way you say

> I will change my PR to add the dependency at parent POM level and use it only 
> for my test in ignite-cassandra.

Igor should review it shortly.

—
Denis

> On Jan 16, 2018, at 5:33 PM, Jason Man, CLSA <jason@clsa.com> wrote:
> 
> Agree with Vladimir/Denis/Igor on using it for specific tests/components.
> 
> What I meant by 'adopt' is to be able use it to facilitate testing of Ignite 
> code somewhere.  It doesn’t mean we should change our overall testing 
> approach overnight and try to use it everywhere.
> 
> In the case of testing code that integrates 3rd party tools (Postgres, MySQL, 
> Cassandra), I think it definitely simplifies the test development effort as 
> well as the time it takes to run the tests.
> 
> @Alexey, I haven't explored using JMockit, but Mockito was just a very 
> popular mocking framework and widely used so it would be less of a learning 
> curve for most developers:
> https://trends.google.com/trends/explore?q=jmockit,mockito
> 
> I will change my PR to add the dependency at parent POM level and use it only 
> for my test in ignite-cassandra.
> 
> Jason
> 
> -Original Message-
> From: Denis Magda [mailto:dma...@apache.org] 
> Sent: Wednesday, January 17, 2018 3:53 AM
> To: dev@ignite.apache.org
> Subject: Re: Adopting mock framework (ex. Mockito) for unit tests
> 
> Agree with Igor’s opinion. If it simplifies Cassandra integration testing 
> cycles and maintenance then we should go for it for *this* component only. No 
> need to push it to all the component we have.
> 
> —
> Denis
> 
>> On Jan 16, 2018, at 10:24 AM, Igor Rudyak <irud...@gmail.com> wrote:
>> 
>> It will be good to clarify what do you mean by adopt? Can't we just 
>> start using it as is for specific cases?
>> 
>> I understand that there are some cases which probably not the best 
>> scenario for Mockito. At the same time there are lot's of other cases 
>> (like in
>> IGNITE-6853 <https://issues.apache.org/jira/browse/IGNITE-6853>) when 
>> tests could be significantly simplified using mock framework.
>> 
>> May be it makes sense to introduce mock framework at the parent POM 
>> and then just reuse it at specific modules for the test cases where 
>> appropriate?
>> 
>> Igor
>> 
>> On Tue, Jan 16, 2018 at 4:27 AM, Vladimir Ozerov 
>> <voze...@gridgain.com>
>> wrote:
>> 
>>> Mocking is a good testing technique, but over years we failed to 
>>> adopt it in Ignite. The reason is high project complexity, when a lot 
>>> of components are interact with each other, and it is very hard to 
>>> extract clean interfaces out of it. We definitely could do better 
>>> with our OOP, but you should remember that good OOP comes at costs - 
>>> more code, more time, worse performance (due to lot's of various 
>>> wrappers). I think of it as a normal case based on my experience - I 
>>> worked with a lot of code bases (Postgres, MySQL, Cassandra, 
>>> Hazelcast, to name a few) - and none of them are clean enough to 
>>> adopt mocking easily. You hardly find clean code in performance-demanded 
>>> projects.
>>> 
>>> TDD is also controversial approach for complex projects. It works 
>>> good when you work on concrete specification of the task and know the 
>>> outcome in advance. But it doesn't work for Ignite - typically we do 
>>> not know outcomes of our activities in advance. Things could change 
>>> dramatically during developments, so TDD for us is waste of time.
>>> 
>>> On the other hand, today we are able to "mock" a lot of internal 
>>> components by hands to test various complex cases. E.g. one can 
>>> easily add his own IO manager to test message drops. You can do virtually 
>>> everything you need.
>>> 
>>> For this reason I doubt mocking is the right approach we should think 
>>> of for core development. But it may do great job for integration with 
>>> 3rd-party products.
>>> 
>>> Vladimir.
>>> 
>>> On Tue, Jan 16, 2018 at 1:34 PM, Alexey Kukushkin < 
>>> kukushkinale...@gmail.com
>>>> wrote:
>>> 
>>>> Hi Jason,
>>>> 
>>>> I heartily support unit testing practices and introducing a mocking 
>>>> framework into ignite development environment. Today I can hardly 
>>>> find a single unit test in Apache Ignite, which does not allow me to 
>>>> use the
>>> best
>>>> TDD an

RE: Adopting mock framework (ex. Mockito) for unit tests

[Jason Man, CLSA]

Agree with Vladimir/Denis/Igor on using it for specific tests/components.

What I meant by 'adopt' is to be able use it to facilitate testing of Ignite 
code somewhere.  It doesn’t mean we should change our overall testing approach 
overnight and try to use it everywhere.

In the case of testing code that integrates 3rd party tools (Postgres, MySQL, 
Cassandra), I think it definitely simplifies the test development effort as 
well as the time it takes to run the tests.

@Alexey, I haven't explored using JMockit, but Mockito was just a very popular 
mocking framework and widely used so it would be less of a learning curve for 
most developers:
https://trends.google.com/trends/explore?q=jmockit,mockito

I will change my PR to add the dependency at parent POM level and use it only 
for my test in ignite-cassandra.

Jason

-Original Message-
From: Denis Magda [mailto:dma...@apache.org] 
Sent: Wednesday, January 17, 2018 3:53 AM
To: dev@ignite.apache.org
Subject: Re: Adopting mock framework (ex. Mockito) for unit tests

Agree with Igor’s opinion. If it simplifies Cassandra integration testing 
cycles and maintenance then we should go for it for *this* component only. No 
need to push it to all the component we have.

—
Denis

> On Jan 16, 2018, at 10:24 AM, Igor Rudyak <irud...@gmail.com> wrote:
> 
> It will be good to clarify what do you mean by adopt? Can't we just 
> start using it as is for specific cases?
> 
> I understand that there are some cases which probably not the best 
> scenario for Mockito. At the same time there are lot's of other cases 
> (like in
> IGNITE-6853 <https://issues.apache.org/jira/browse/IGNITE-6853>) when 
> tests could be significantly simplified using mock framework.
> 
> May be it makes sense to introduce mock framework at the parent POM 
> and then just reuse it at specific modules for the test cases where 
> appropriate?
> 
> Igor
> 
> On Tue, Jan 16, 2018 at 4:27 AM, Vladimir Ozerov 
> <voze...@gridgain.com>
> wrote:
> 
>> Mocking is a good testing technique, but over years we failed to 
>> adopt it in Ignite. The reason is high project complexity, when a lot 
>> of components are interact with each other, and it is very hard to 
>> extract clean interfaces out of it. We definitely could do better 
>> with our OOP, but you should remember that good OOP comes at costs - 
>> more code, more time, worse performance (due to lot's of various 
>> wrappers). I think of it as a normal case based on my experience - I 
>> worked with a lot of code bases (Postgres, MySQL, Cassandra, 
>> Hazelcast, to name a few) - and none of them are clean enough to 
>> adopt mocking easily. You hardly find clean code in performance-demanded 
>> projects.
>> 
>> TDD is also controversial approach for complex projects. It works 
>> good when you work on concrete specification of the task and know the 
>> outcome in advance. But it doesn't work for Ignite - typically we do 
>> not know outcomes of our activities in advance. Things could change 
>> dramatically during developments, so TDD for us is waste of time.
>> 
>> On the other hand, today we are able to "mock" a lot of internal 
>> components by hands to test various complex cases. E.g. one can 
>> easily add his own IO manager to test message drops. You can do virtually 
>> everything you need.
>> 
>> For this reason I doubt mocking is the right approach we should think 
>> of for core development. But it may do great job for integration with 
>> 3rd-party products.
>> 
>> Vladimir.
>> 
>> On Tue, Jan 16, 2018 at 1:34 PM, Alexey Kukushkin < 
>> kukushkinale...@gmail.com
>>> wrote:
>> 
>>> Hi Jason,
>>> 
>>> I heartily support unit testing practices and introducing a mocking 
>>> framework into ignite development environment. Today I can hardly 
>>> find a single unit test in Apache Ignite, which does not allow me to 
>>> use the
>> best
>>> TDD and CI/CD practices like running tests on every commit (or even 
>>> on every "save file"!).
>>> 
>>> I recently started developing an isolated component based on Apache
>> Ignite
>>> and, since I use TDD and write lots of unit tests, I had to add a 
>>> mocking framework to my project. I started from Mockito (version 
>>> 1.something) and found I could not do some things with Mockito due 
>>> to Ignite currently not designed for unit testing. I believe I could 
>>> not find a way to mock some private initialisation block with Mockito.
>>> 
>>> Thus, I switched to JMockit - it allowed me to mock what I wanted 
>>> and it se

Re: Adopting mock framework (ex. Mockito) for unit tests

[Denis Magda]

Agree with Igor’s opinion. If it simplifies Cassandra integration testing 
cycles and maintenance then we should go for it for *this* component only. No 
need to push it to all the component we have.

—
Denis

> On Jan 16, 2018, at 10:24 AM, Igor Rudyak  wrote:
> 
> It will be good to clarify what do you mean by adopt? Can't we just start
> using it as is for specific cases?
> 
> I understand that there are some cases which probably not the best scenario
> for Mockito. At the same time there are lot's of other cases (like in
> IGNITE-6853 ) when tests
> could be significantly simplified using mock framework.
> 
> May be it makes sense to introduce mock framework at the parent POM and
> then just reuse it at specific modules for the test cases where appropriate?
> 
> Igor
> 
> On Tue, Jan 16, 2018 at 4:27 AM, Vladimir Ozerov 
> wrote:
> 
>> Mocking is a good testing technique, but over years we failed to adopt it
>> in Ignite. The reason is high project complexity, when a lot of components
>> are interact with each other, and it is very hard to extract clean
>> interfaces out of it. We definitely could do better with our OOP, but you
>> should remember that good OOP comes at costs - more code, more time, worse
>> performance (due to lot's of various wrappers). I think of it as a normal
>> case based on my experience - I worked with a lot of code bases (Postgres,
>> MySQL, Cassandra, Hazelcast, to name a few) - and none of them are clean
>> enough to adopt mocking easily. You hardly find clean code in
>> performance-demanded projects.
>> 
>> TDD is also controversial approach for complex projects. It works good when
>> you work on concrete specification of the task and know the outcome in
>> advance. But it doesn't work for Ignite - typically we do not know outcomes
>> of our activities in advance. Things could change dramatically during
>> developments, so TDD for us is waste of time.
>> 
>> On the other hand, today we are able to "mock" a lot of internal components
>> by hands to test various complex cases. E.g. one can easily add his own IO
>> manager to test message drops. You can do virtually everything you need.
>> 
>> For this reason I doubt mocking is the right approach we should think of
>> for core development. But it may do great job for integration with
>> 3rd-party products.
>> 
>> Vladimir.
>> 
>> On Tue, Jan 16, 2018 at 1:34 PM, Alexey Kukushkin <
>> kukushkinale...@gmail.com
>>> wrote:
>> 
>>> Hi Jason,
>>> 
>>> I heartily support unit testing practices and introducing a mocking
>>> framework into ignite development environment. Today I can hardly find a
>>> single unit test in Apache Ignite, which does not allow me to use the
>> best
>>> TDD and CI/CD practices like running tests on every commit (or even on
>>> every "save file"!).
>>> 
>>> I recently started developing an isolated component based on Apache
>> Ignite
>>> and, since I use TDD and write lots of unit tests, I had to add a mocking
>>> framework to my project. I started from Mockito (version 1.something) and
>>> found I could not do some things with Mockito due to Ignite currently not
>>> designed for unit testing. I believe I could not find a way to mock some
>>> private initialisation block with Mockito.
>>> 
>>> Thus, I switched to JMockit - it allowed me to mock what I wanted and it
>>> seems you can mock virtually everything with JMockit.
>>> 
>>> I know that a situation when you have to mock something private or static
>>> indicates not very modular and extendable design but you do not have much
>>> of a choice with Ignite since you already have huge amount of code and it
>>> would be really hard to refactor everything to make it testable since
>>> Ignite development process is heavy and your project could be stuck
>> waiting
>>> for Ignite changes.
>>> 
>>> Did you consider JMockit over Mockito? It seems JMockit supports both
>>> record-replay-verity and setup-run-verify models as well as BDD semantics
>>> API.
>>> 
>> 

Re: Adopting mock framework (ex. Mockito) for unit tests

[Igor Rudyak]

It will be good to clarify what do you mean by adopt? Can't we just start
using it as is for specific cases?

I understand that there are some cases which probably not the best scenario
for Mockito. At the same time there are lot's of other cases (like in
IGNITE-6853 ) when tests
could be significantly simplified using mock framework.

May be it makes sense to introduce mock framework at the parent POM and
then just reuse it at specific modules for the test cases where appropriate?

Igor

On Tue, Jan 16, 2018 at 4:27 AM, Vladimir Ozerov 
wrote:

> Mocking is a good testing technique, but over years we failed to adopt it
> in Ignite. The reason is high project complexity, when a lot of components
> are interact with each other, and it is very hard to extract clean
> interfaces out of it. We definitely could do better with our OOP, but you
> should remember that good OOP comes at costs - more code, more time, worse
> performance (due to lot's of various wrappers). I think of it as a normal
> case based on my experience - I worked with a lot of code bases (Postgres,
> MySQL, Cassandra, Hazelcast, to name a few) - and none of them are clean
> enough to adopt mocking easily. You hardly find clean code in
> performance-demanded projects.
>
> TDD is also controversial approach for complex projects. It works good when
> you work on concrete specification of the task and know the outcome in
> advance. But it doesn't work for Ignite - typically we do not know outcomes
> of our activities in advance. Things could change dramatically during
> developments, so TDD for us is waste of time.
>
> On the other hand, today we are able to "mock" a lot of internal components
> by hands to test various complex cases. E.g. one can easily add his own IO
> manager to test message drops. You can do virtually everything you need.
>
> For this reason I doubt mocking is the right approach we should think of
> for core development. But it may do great job for integration with
> 3rd-party products.
>
> Vladimir.
>
> On Tue, Jan 16, 2018 at 1:34 PM, Alexey Kukushkin <
> kukushkinale...@gmail.com
> > wrote:
>
> > Hi Jason,
> >
> > I heartily support unit testing practices and introducing a mocking
> > framework into ignite development environment. Today I can hardly find a
> > single unit test in Apache Ignite, which does not allow me to use the
> best
> > TDD and CI/CD practices like running tests on every commit (or even on
> > every "save file"!).
> >
> > I recently started developing an isolated component based on Apache
> Ignite
> > and, since I use TDD and write lots of unit tests, I had to add a mocking
> > framework to my project. I started from Mockito (version 1.something) and
> > found I could not do some things with Mockito due to Ignite currently not
> > designed for unit testing. I believe I could not find a way to mock some
> > private initialisation block with Mockito.
> >
> > Thus, I switched to JMockit - it allowed me to mock what I wanted and it
> > seems you can mock virtually everything with JMockit.
> >
> > I know that a situation when you have to mock something private or static
> > indicates not very modular and extendable design but you do not have much
> > of a choice with Ignite since you already have huge amount of code and it
> > would be really hard to refactor everything to make it testable since
> > Ignite development process is heavy and your project could be stuck
> waiting
> > for Ignite changes.
> >
> > Did you consider JMockit over Mockito? It seems JMockit supports both
> > record-replay-verity and setup-run-verify models as well as BDD semantics
> > API.
> >
>

Re: Adopting mock framework (ex. Mockito) for unit tests

[Vladimir Ozerov]

Mocking is a good testing technique, but over years we failed to adopt it
in Ignite. The reason is high project complexity, when a lot of components
are interact with each other, and it is very hard to extract clean
interfaces out of it. We definitely could do better with our OOP, but you
should remember that good OOP comes at costs - more code, more time, worse
performance (due to lot's of various wrappers). I think of it as a normal
case based on my experience - I worked with a lot of code bases (Postgres,
MySQL, Cassandra, Hazelcast, to name a few) - and none of them are clean
enough to adopt mocking easily. You hardly find clean code in
performance-demanded projects.

TDD is also controversial approach for complex projects. It works good when
you work on concrete specification of the task and know the outcome in
advance. But it doesn't work for Ignite - typically we do not know outcomes
of our activities in advance. Things could change dramatically during
developments, so TDD for us is waste of time.

On the other hand, today we are able to "mock" a lot of internal components
by hands to test various complex cases. E.g. one can easily add his own IO
manager to test message drops. You can do virtually everything you need.

For this reason I doubt mocking is the right approach we should think of
for core development. But it may do great job for integration with
3rd-party products.

Vladimir.

On Tue, Jan 16, 2018 at 1:34 PM, Alexey Kukushkin  wrote:

> Hi Jason,
>
> I heartily support unit testing practices and introducing a mocking
> framework into ignite development environment. Today I can hardly find a
> single unit test in Apache Ignite, which does not allow me to use the best
> TDD and CI/CD practices like running tests on every commit (or even on
> every "save file"!).
>
> I recently started developing an isolated component based on Apache Ignite
> and, since I use TDD and write lots of unit tests, I had to add a mocking
> framework to my project. I started from Mockito (version 1.something) and
> found I could not do some things with Mockito due to Ignite currently not
> designed for unit testing. I believe I could not find a way to mock some
> private initialisation block with Mockito.
>
> Thus, I switched to JMockit - it allowed me to mock what I wanted and it
> seems you can mock virtually everything with JMockit.
>
> I know that a situation when you have to mock something private or static
> indicates not very modular and extendable design but you do not have much
> of a choice with Ignite since you already have huge amount of code and it
> would be really hard to refactor everything to make it testable since
> Ignite development process is heavy and your project could be stuck waiting
> for Ignite changes.
>
> Did you consider JMockit over Mockito? It seems JMockit supports both
> record-replay-verity and setup-run-verify models as well as BDD semantics
> API.
>

Re: Adopting mock framework (ex. Mockito) for unit tests

[Alexey Kukushkin]

Hi Jason,

I heartily support unit testing practices and introducing a mocking
framework into ignite development environment. Today I can hardly find a
single unit test in Apache Ignite, which does not allow me to use the best
TDD and CI/CD practices like running tests on every commit (or even on
every "save file"!).

I recently started developing an isolated component based on Apache Ignite
and, since I use TDD and write lots of unit tests, I had to add a mocking
framework to my project. I started from Mockito (version 1.something) and
found I could not do some things with Mockito due to Ignite currently not
designed for unit testing. I believe I could not find a way to mock some
private initialisation block with Mockito.

Thus, I switched to JMockit - it allowed me to mock what I wanted and it
seems you can mock virtually everything with JMockit.

I know that a situation when you have to mock something private or static
indicates not very modular and extendable design but you do not have much
of a choice with Ignite since you already have huge amount of code and it
would be really hard to refactor everything to make it testable since
Ignite development process is heavy and your project could be stuck waiting
for Ignite changes.

Did you consider JMockit over Mockito? It seems JMockit supports both
record-replay-verity and setup-run-verify models as well as BDD semantics
API.

Adopting mock framework (ex. Mockito) for unit tests

[Jason Man, CLSA]

Hi Igniters,

I'd like to discuss the topic of adopting a mock framework such as Mockito into 
Ignite's project for writing unit tests.

Here's a simple article that illustrate why using a mock object for testing is 
necessary, and why using a framework is better than doing it yourself:
https://zeroturnaround.com/rebellabs/how-to-mock-up-your-unit-test-environment-to-create-alternate-realities/

Here's Mokito's website which also illustrate the Why and How:
http://site.mockito.org/

Then, here's my PR for one of the bug fixes I'm trying to fix in Ignite that 
prompted me to use mocks:
https://github.com/apache/ignite/pull/3088/files

In the case of my unit test, not using a mocking framework will be difficult to 
test certain negative behaviour of Cassandra.  On the other hand, manually 
mocking the objects (instead of using a framework) will result in hundreds of 
lines of boiler plate code.  Or in some cases, it's ugly to mock an object 
where it has a package-private constructor instead of a public one. (you'd have 
to put your mock object in the same package...)

Overall, I think introducing a mocking framework can help us write unit tests 
that have better coverage of code, especially mocking behaviour of external 
dependencies (such as Cassandra).

What do you guys think?

Regards,
Jason

The content of this communication is intended for the recipient and is subject 
to CLSA Legal and Regulatory Notices.
These can be viewed at https://www.clsa.com/disclaimer.html or sent to you upon 
request.
Please consider before printing. CLSA is ISO14001 certified and committed to 
reducing its impact on the environment.