"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 ...
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 ...
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 ...
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.
Positive testing is the testing of functionality that we expect to work.
1) The user enters the wrong username and password combination. 2) The user is expected not to get logged in. 3) Test that the user is not logged in.
Negative testing is the test of cases that we expect to fail.
1) The user types in an invalid character in the ...
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 ...
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 ...
You should rely on specific exceptions you can propagate up or special return values since your code will be living with all sorts of code in an app that lives with all sorts of apps in its overall system. Assertions in source code cause clutter and using them in lieu of properly defined behavior leaves you with all sorts of headaches in the long term since ...
I have designed and implemented processes in a software company that were certified ISO9001:2007. There have been updates to the standard since 2007 so there may be additional requirements that I am not aware of... however:
The ISO9001 standard is about ensuring that your company designs and implements processes that have feedback loops for improving the ...
Reason I'm asking is because integration testing is suppose to make sure our classes integrate together by definition
This is wrong.
Classes existed long before the idea of integration testing. Integration testing is simply testing without requiring isolated units. If you can isolate your units you have unit testing. A unit is a cohesive group of local ...
What is the Requirement you are testing?
If the requirement is that your XML fits a specific format, say, SOME-SPEC-1234, then yes, you'll need to test against that specific format.
If the requirement is that what you write can be read back (mainly by your SW) with no loss in data, then, IMO, a better test is to do that: create the data, write it as XML or ...
I am working with such automated tests since several years, and though we have several hundred of complex XML files in one test suite, they are very well maintainable, even if some of the tests break from time to time.
Our team accomplishes this in the following way:
We use custom "diff" algorithms to detect differences between different the actual and ...
Tests of the kind you describe are brittle. As you've correctly pointed out, small changes are likely to break a significant number of the existing tests. But that is by design; tests like these are meant to break over the smallest change to your code. They are the proverbial "canary in the coal mine," meant to detect breaking changes in your code before ...