var mainLogger = LoggerFactory.CreateLogger(nameof(Program)); LogEntry.New().Debug().Message("Logging initialized.").Log(mainLogger);
This should really be split into two lines. Not sure what happened, but I'm sure it was a mistake.
var mainLogger = LoggerFactory.CreateLogger(nameof(Program));
I went through the very same conflict and eventually looked at what other frameworks were doing. What you'll find with the above implementation is that it is okay for a couple hundred tests, but soon it will become unbearable slow. What I started doing was wrapping my integration tests in transactions. I've written a blog post that goes into the details here....
Use the 2nd version - i.e. use the path helper methods, don't use strings. Or use a 3rd one, detailed below.
Ideally, you test your routes separately from the controller (in test/routes//spec/routes/ files). That'll test that "/users/homer/edit" indeed routes to the users#edit action. Provided your using Rails' standard resourceful routes, you don't need ...
First of all I would like to say that, in my opinion, testing API in a such way is wrong, because how does such unit test behave when:
developer machine does not have Internet connection?
developer machine does not have proper certificates?
machine that run test does not have acces to such domain?
external API URL changed?
some new requirements (headers, ...
The documentation for CMake urges you not to use glob to detect every source file. The reasoning behind it is this: if you add a file it will not detect it. You will have to rerun CMake manually every time you add or remove source files.
If that is acceptable to you, then it is okay to use globbing, just be advised that it is generally not considered a good ...
There are several possible steps you can take to increase readability to your code, depending on how much control of the code you have and how much implementation details you which to hide.
Separate default values from database loading logic
By initializing setupConfiguration with default values by named properties and moving the database loading logic ...
I think you're right to be suspicious of your test setup. Given your code, I imagine you're using #to_json/#as_json in your controllers already, which in effect reduces your test to:
assert_equal record.as_json, record.as_json
which doesn't prove much of anything.
It can also hide bugs. For instance, say your product attributes are name and an optional ...
From a once over and reading some Jasmine docs:
I am not a big fan of _db and _testContext, I see no reason for the underscores.
It is not guaranteed that _db will be set in new MyCtorFunction(_db).myMethod(_testContext.assertions);, so you should check for that prior to calling.
You did not tell us what database (API) you are using, so we cannot tell ...
My immediate thought is that the function is just doing too many things.
It'd be simpler to just return a mixed-case string of a specific length. Done.
Want that string to be all-uppercase? Just call getRandomString(n).toUpperCase().
All-lowercase. Call getRandomString(n).toUpperCase().
Want it to have a separator between each letter? Call ...
Yes, this is the way to do error handling in Go. By design, you can't let exceptions propagate to the callers "silently", you have to consider what makes sense at each step. I found that on large-scale projects, it makes it significantly easier to predict and test the error handling behavior of your code. It also forces you to put the error handling first, ...
This code is very easy to understand, which is great! I like that you used full words for the variable names rather than abbreviating everything to single character names.
In alloc_matrix(), if there is a failure to allocate memory, it calls abort(). This is going to make it very difficult to test! If it attempts to allocate and fails, it aborts ...
You allow a server to reuse an existing context when calling BeginScope. Does this mean multiple integration tests could reuse a context? If so, how do you handle disposal of the context? Your example shows one test that handles disposal of a possibly shared context.
public ITeapotServerContext BeginScope()
// CR: who should be allowed to handle the ...
router object is a mock, and
the fact that it calls some method - without checking its result
You have a unit test, more specifically a whitebox test, as opposed to a blackbox test that tests the output of some method.
For it to become an integration test, you would have use a router instead of a mock.
Your code is non-reentrant; that is, it can't be called by more than one user at a time due to the global LEAF. Don't have that as a global. It should be passed into your functions, either as a member of a struct if appropriate, or a separate argument.
Use typedef so that you don't have to write struct node 100 times.
Use const where ...
You can have a separate project for your Dockfile and let gitlab keep the image in a container repository. That way you will not need to rebuild the image every build and you can reuse the container in other project without rebuilding it.
As far as I can tell, the use case you are targeting is already supported by the completion callback, even when you are using promises. I have had good luck using the following pattern to ensure that asynchronously initialized, promise based libraries are fully initialized before testing begins:
// Note the function now accepts argument `done`
I prefer Option A over Option B. While you do then end up resting both the port and the adapter in one go, the port and adapter together constitute the unit you are trying to test: the piece of code that allows you to manipulate the widget in question.
Option B, in my opinion, is perhaps a tad too granular.
The main piece of complexity comes from the way you are converting Math.random() to a sequence of letters. Although the solution is short, as you have found out, the number of letters you get back is completely random, which is troublesome. (It's not even clear to me if converting to radix 36 will give you a uniform distribution of letters.) It also makes ...
For try/catch, statements you should ask yourself: what are you trying to achieve? Do you need to handle the error differently in one controller compared to the rest of the application? If yes, then wrap the entire contents of your method.
If no, Laravel implements a global error handler. You simply need to throw your exceptions and Laravel handles the ...
This is not usually a good idea:
If you don't need to do anything, the code is more readable by omitting the try block altogether.
You should be able to simplify your code by putting more functionality into IntegrationTest. Can you move Init and TestCleanup into the base, so you don't have to redefine them for every subclass?