Okay so I'll try answer the meta-question about unit testing with dependencies. As others have pointed out, your examples aren't really unit tests, which makes it a little difficult to redo them.
First point. the aim of a unit test is to test some behaviour of the system, in an isolated manner. This is important to keep in mind as not all dependencies are the same, and their nature dictates how you'll handle them.
Some dependencies will be the source of state, some will be the source of domain logic/knowledge and others will be further system behaviour.
So lets take the following code: (Implied is the code to set the fields which hold the dependencies)
public class House {
private TemperatureSensor thermometer;
...
public bool IsLoungeTooHot() {
return thermometer.CurrentTemperature > 20;
}
}
It's a simple class with a single bit of behaviour checking the lounge temperature and a single dependency on a thermometer.
So thermometer is the source of the data and as such it is always faked since the test needs to be able to use multiple temperatures to ensure it works (at the very least return temp below 20 and above 20)
Now if we were to extend the code to
public class House {
private TemperatureSensor thermometer;
private Thermostat thermostat;
...
public bool IsLoungeTooHot() {
return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
}
}
So we now the desired temperature is no longer a constant but rather retrieved from a domain object. So the thermostat dependency is something that will almost never be faked (safe to read never but there can be edge cases). The reason why we don't want to fake this is to protect ourselves against test fragility.
As the writers of the code we could create a perfect fake of the Thermostat. However it would only be perfect at the moment we wrote the test. At some point down the line the behaviour of Thermostat could change, and if we had used a fake there is a very good chance we would not notice.
Third and final extension of the code:
public class House {
private TemperatureSensor thermometer;
private Thermostat thermostat;
private DataRepository repo;
...
public bool IsLoungeTooHot() {
repo.Audit("IsLoungTooHot");
return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
}
}
The repo dependency similar to the thermostat dependency, it is additional system behaviour. However in this specific case we would replace it with a fake because using the real database would break the isolation we need to ensure that this test doesn't affect other tests that may also be running.
A bit of a wall of text, hope it's made things a little clearer.
fake - stub/mock see http://stackoverflow.com/a/346440/5889 https://stackoverflow.com/a/346440/5889 for a good explanation of the differences.
Okay so I'll try answer the meta-question about unit testing with dependencies. As others have pointed out, your examples aren't really unit tests, which makes it a little difficult to redo them.
First point. the aim of a unit test is to test some behaviour of the system, in an isolated manner. This is important to keep in mind as not all dependencies are the same, and their nature dictates how you'll handle them.
Some dependencies will be the source of state, some will be the source of domain logic/knowledge and others will be further system behaviour.
So lets take the following code: (Implied is the code to set the fields which hold the dependencies)
public class House {
private TemperatureSensor thermometer;
...
public bool IsLoungeTooHot() {
return thermometer.CurrentTemperature > 20;
}
}
It's a simple class with a single bit of behaviour checking the lounge temperature and a single dependency on a thermometer.
So thermometer is the source of the data and as such it is always faked since the test needs to be able to use multiple temperatures to ensure it works (at the very least return temp below 20 and above 20)
Now if we were to extend the code to
public class House {
private TemperatureSensor thermometer;
private Thermostat thermostat;
...
public bool IsLoungeTooHot() {
return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
}
}
So we now the desired temperature is no longer a constant but rather retrieved from a domain object. So the thermostat dependency is something that will almost never be faked (safe to read never but there can be edge cases). The reason why we don't want to fake this is to protect ourselves against test fragility.
As the writers of the code we could create a perfect fake of the Thermostat. However it would only be perfect at the moment we wrote the test. At some point down the line the behaviour of Thermostat could change, and if we had used a fake there is a very good chance we would not notice.
Third and final extension of the code:
public class House {
private TemperatureSensor thermometer;
private Thermostat thermostat;
private DataRepository repo;
...
public bool IsLoungeTooHot() {
repo.Audit("IsLoungTooHot");
return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
}
}
The repo dependency similar to the thermostat dependency, it is additional system behaviour. However in this specific case we would replace it with a fake because using the real database would break the isolation we need to ensure that this test doesn't affect other tests that may also be running.
A bit of a wall of text, hope it's made things a little clearer.
fake - stub/mock see http://stackoverflow.com/a/346440/5889 for a good explanation of the differences.
Okay so I'll try answer the meta-question about unit testing with dependencies. As others have pointed out, your examples aren't really unit tests, which makes it a little difficult to redo them.
First point. the aim of a unit test is to test some behaviour of the system, in an isolated manner. This is important to keep in mind as not all dependencies are the same, and their nature dictates how you'll handle them.
Some dependencies will be the source of state, some will be the source of domain logic/knowledge and others will be further system behaviour.
So lets take the following code: (Implied is the code to set the fields which hold the dependencies)
public class House {
private TemperatureSensor thermometer;
...
public bool IsLoungeTooHot() {
return thermometer.CurrentTemperature > 20;
}
}
It's a simple class with a single bit of behaviour checking the lounge temperature and a single dependency on a thermometer.
So thermometer is the source of the data and as such it is always faked since the test needs to be able to use multiple temperatures to ensure it works (at the very least return temp below 20 and above 20)
Now if we were to extend the code to
public class House {
private TemperatureSensor thermometer;
private Thermostat thermostat;
...
public bool IsLoungeTooHot() {
return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
}
}
So we now the desired temperature is no longer a constant but rather retrieved from a domain object. So the thermostat dependency is something that will almost never be faked (safe to read never but there can be edge cases). The reason why we don't want to fake this is to protect ourselves against test fragility.
As the writers of the code we could create a perfect fake of the Thermostat. However it would only be perfect at the moment we wrote the test. At some point down the line the behaviour of Thermostat could change, and if we had used a fake there is a very good chance we would not notice.
Third and final extension of the code:
public class House {
private TemperatureSensor thermometer;
private Thermostat thermostat;
private DataRepository repo;
...
public bool IsLoungeTooHot() {
repo.Audit("IsLoungTooHot");
return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
}
}
The repo dependency similar to the thermostat dependency, it is additional system behaviour. However in this specific case we would replace it with a fake because using the real database would break the isolation we need to ensure that this test doesn't affect other tests that may also be running.
A bit of a wall of text, hope it's made things a little clearer.
fake - stub/mock see https://stackoverflow.com/a/346440/5889 for a good explanation of the differences.
Okay so I'll try answer the meta-question about unit testing with dependencies. As others have pointed out, your examples aren't really unit tests, which makes it a little difficult to redo them.
First point. the aim of a unit test is to test some behaviour of the system, in an isolated manner. This is important to keep in mind as not all dependencies are the same, and their nature dictates how you'll handle them.
Some dependencies will be the source of state, some will be the source of domain logic/knowledge and others will be further system behaviour.
So lets take the following code: (Implied is the code to set the fields which hold the dependencies)
public class House {
private TemperatureSensor thermometer;
...
public bool IsLoungeTooHot() {
return thermometer.CurrentTemperature > 20;
}
}
It's a simple class with a single bit of behaviour checking the lounge temperature and a single dependency on a thermometer.
So thermometer is the source of the data and as such it is always faked since the test needs to be able to use multiple temperatures to ensure it works (at the very least return temp below 20 and above 20)
Now if we were to extend the code to
public class House {
private TemperatureSensor thermometer;
private Thermostat thermostat;
...
public bool IsLoungeTooHot() {
return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
}
}
So we now the desired temperature is no longer a constant but rather retrieved from a domain object. So the thermostat dependency is something that will almost never be faked (safe to read never but there can be edge cases) since the behaviour you're testing. The reason why we don't want to fake this is to protect ourselves against test fragility.
As the writers of the code we could create a resultperfect fake of the interactionThermostat. However it would only be perfect at the moment we wrote the test. At some point down the line the behaviour of these two objectsThermostat could change, and if we had used a fake there is a very good chance we would not notice.
Third and final extension of the code:
public class House {
private TemperatureSensor thermometer;
private Thermostat thermostat;
private DataRepository repo;
...
public bool IsLoungeTooHot() {
repo.Audit("IsLoungTooHot");
return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
}
}
The repo dependency similar to the thermostat dependency, it is additional system behaviour. However in this specific case we would replace it with a fake because using the real database would break the isolation we need to ensure that this test doesn't affect other tests that may also be running.
A bit of a wall of text, hope it's made things a little clearer.
fake - stub/mock see http://stackoverflow.com/a/346440/5889 for a good explanation of the differences.
Okay so I'll try answer the meta-question about unit testing with dependencies. As others have pointed out, your examples aren't really unit tests, which makes it a little difficult to redo them.
First point. the aim of a unit test is to test some behaviour of the system, in an isolated manner. This is important to keep in mind as not all dependencies are the same, and their nature dictates how you'll handle them.
Some dependencies will be the source of state, some will be the source of domain logic/knowledge and others will be further system behaviour.
So lets take the following code: (Implied is the code to set the fields which hold the dependencies)
public class House {
private TemperatureSensor thermometer;
...
public bool IsLoungeTooHot() {
return thermometer.CurrentTemperature > 20;
}
}
It's a simple class with a single bit of behaviour checking the lounge temperature and a single dependency on a thermometer.
So thermometer is the source of the data and as such it is always faked since the test needs to be able to use multiple temperatures to ensure it works (at the very least return temp below 20 and above 20)
Now if we were to extend the code to
public class House {
private TemperatureSensor thermometer;
private Thermostat thermostat;
...
public bool IsLoungeTooHot() {
return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
}
}
So we now the desired temperature is no longer a constant but rather retrieved from a domain object. So the thermostat dependency is something that will almost never be faked (safe to read never but there can be edge cases) since the behaviour you're testing is a result of the interaction of these two objects.
Third and final extension of the code:
public class House {
private TemperatureSensor thermometer;
private Thermostat thermostat;
private DataRepository repo;
...
public bool IsLoungeTooHot() {
repo.Audit("IsLoungTooHot");
return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
}
}
The repo dependency similar to the thermostat dependency, it is additional system behaviour. However in this specific case we would replace it with a fake because using the real database would break the isolation we need to ensure that this test doesn't affect other tests that may also be running.
A bit of a wall of text, hope it's made things a little clearer.
fake - stub/mock see http://stackoverflow.com/a/346440/5889 for a good explanation of the differences.
Okay so I'll try answer the meta-question about unit testing with dependencies. As others have pointed out, your examples aren't really unit tests, which makes it a little difficult to redo them.
First point. the aim of a unit test is to test some behaviour of the system, in an isolated manner. This is important to keep in mind as not all dependencies are the same, and their nature dictates how you'll handle them.
Some dependencies will be the source of state, some will be the source of domain logic/knowledge and others will be further system behaviour.
So lets take the following code: (Implied is the code to set the fields which hold the dependencies)
public class House {
private TemperatureSensor thermometer;
...
public bool IsLoungeTooHot() {
return thermometer.CurrentTemperature > 20;
}
}
It's a simple class with a single bit of behaviour checking the lounge temperature and a single dependency on a thermometer.
So thermometer is the source of the data and as such it is always faked since the test needs to be able to use multiple temperatures to ensure it works (at the very least return temp below 20 and above 20)
Now if we were to extend the code to
public class House {
private TemperatureSensor thermometer;
private Thermostat thermostat;
...
public bool IsLoungeTooHot() {
return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
}
}
So we now the desired temperature is no longer a constant but rather retrieved from a domain object. So the thermostat dependency is something that will almost never be faked (safe to read never but there can be edge cases). The reason why we don't want to fake this is to protect ourselves against test fragility.
As the writers of the code we could create a perfect fake of the Thermostat. However it would only be perfect at the moment we wrote the test. At some point down the line the behaviour of Thermostat could change, and if we had used a fake there is a very good chance we would not notice.
Third and final extension of the code:
public class House {
private TemperatureSensor thermometer;
private Thermostat thermostat;
private DataRepository repo;
...
public bool IsLoungeTooHot() {
repo.Audit("IsLoungTooHot");
return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
}
}
The repo dependency similar to the thermostat dependency, it is additional system behaviour. However in this specific case we would replace it with a fake because using the real database would break the isolation we need to ensure that this test doesn't affect other tests that may also be running.
A bit of a wall of text, hope it's made things a little clearer.
fake - stub/mock see http://stackoverflow.com/a/346440/5889 for a good explanation of the differences.
Okay so I'll try answer the meta-question about unit testing with dependencies. As others have pointed out, your examples aren't really unit tests, which makes it a little difficult to redo them.
First point. the aim of a unit test is to test some behaviour of the system, in an isolated manner. This is important to keep in mind as not all dependencies are the same, and their nature dictates how you'll handle them.
Some dependencies will be the source of state, some will be the source of domain logic/knowledge and others will be further system behaviour.
So lets take the following code: (Implied is the code to set the fields which hold the dependencies)
public class House {
private TemperatureSensor thermometer;
...
public bool IsLoungeTooHot() {
return thermometer.CurrentTemperature > 20;
}
}
It's a simple class with a single bit of behaviour checking the lounge temperature and a single dependency on a thermometer.
So thermometer is the source of the data and as such it is always faked since the test needs to be able to use multiple temperatures to ensure it works (at the very least return temp below 20 and above 20)
Now if we were to extend the code to
public class House {
private TemperatureSensor thermometer;
private Thermostat thermostat;
...
public bool IsLoungeTooHot() {
return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
}
}
So we now the desired temperature is no longer a constant but rather retrieved from a domain object. So the thermostat dependency is something that will almost never be faked (safe to read never but there can be edge cases) since the behaviour you're testing is a result of the interaction of these two objects.
Third and final extension of the code:
public class House {
private TemperatureSensor thermometer;
private Thermostat thermostat;
private DataRepository repo;
...
public bool IsLoungeTooHot() {
repo.Audit("IsLoungTooHot");
return thermometer.CurrentTemperature > thermostat.DesiredTemperature;
}
}
The repo dependency similar to the thermostat dependency, it is additional system behaviour. However in this specific case we would replace it with a fake because using the real database would break the isolation we need to ensure that this test doesn't affect other tests that may also be running.
A bit of a wall of text, hope it's made things a little clearer.
fake - stub/mock see http://stackoverflow.com/a/346440/5889 for a good explanation of the differences.