You have to test all the scenarios which are defined in your acceptance criteria.
When you have an array of options like this I would use Data driven tests
public void CanFileOpen(user,file,expected)
var actual ...
No, it is not a good approach. It is actually a terrible and common one. I would say it is a testing anti-pattern.
End-to-End tests like you describe are high-effort, low-value and have high risk of breaking when making code changes. The main issue here is that lots of software has it's tests written after the coding is complete, and adding stable and fast ...
The nice thing about architectural patterns is that they are largely language independent. Some languages may have better or worse support for the basic constructs that a particular pattern is built upon.
Many architectural patterns are built upon Object Oriented concepts. C does not have built-in OO features, but you can actually implement OO designs in C.
Brevity eludes me. I was commenting on randomized data driven tests and just wanted to keep going.
For the case at hand, with only four possible input points. I agree on enumerating all posilibities. However, this is a simple case.
I really want to point out that randomized data driven tests are useful. They have the potential to express the behaviour of ...
In these senarios I want to test two things
Do my tests pass for each individual server
Do my tests pass for the load balanced endpoint
In order to test individual servers I need to be able to address them directly. This can be done by going direct to each box, or by providing a routing parameter to the LB which bypasses the nomal host selection.
I can ...
PowerShell is a script language. It is designed to rig-up function blocks created using programming languages. The pitfall to application programmers when they start using PowerShell is that they approach it as a 3rd generation programming language. They take their experience from C/Java/Pascal and try to map that to the PowerShell environment. This soon ...
Each line of code you write needs to be tested and maintained. If you get intermittent build failures due to defects in the scripts, then the PowerShell scripts are getting difficult to test. If extending the PowerShell script is becoming difficult, then maintainability is becoming an issue. When deciding to go from a "simple" scripting language to something ...
End-To-End tests have the following benefits
They are very close to what the end user sees (often they directly test what the end user sees). They can directly test the fitness for purpose for the product user.
They test thousands of lines of code per test
They test the environment the product is deployed into
So they do a couple things unit tests can't do,...
"The environment" usually has the same interface as a Map/Dictionary, or a lookup function -- you pass in a string, you get a string returned.
// getenv: String -> String
String path = System.getenv("PATH")
My first choice is generally to run the tests in the correctly specified environment. After all, that's what the environment is for.
But if I need ...
What do you want to verify in your test?
If you want to verify that the Access-Control-Allow-Origin header is correctly filled according to the environment you are running in, then you should exactly read the expected value from the dotenv file, so you can know that its value is filled in correctly in the header.
You would need a proper review process to ...
Assertions to me were always about documenting my assumptions related to the functioning of an algorithm.
They communicate that, at this point, I’m asserting something should be true—likely, it’s a property I can prove to be true of a functioning implementation. For example, in a Semaphore implementation, I might have asserts that the value is never below ...