I am trying to write a Django (4) test. It has to work differently depending on the DEBUG constant in my settings.py.
So I started with something like:
def my_test(self):
from django.conf import settings
if settings.DEBUG:
....
else:
....
I noticed the code never executed the first part of the if so I added:
print(settings.DEBUG)
And I noticed this prints always False. Even if DEBUG is set to True in my settings.py.
I tried with some others constants there (INSTALLED_APPS, ALLOWED_HOSTS) and all of them return the correct value.
Why is that? How to access the real DEBUG constant in my settings.py?
Adding --debug-mode flag solved the issue:
python manage.py test --debug-mode
--debug-mode
Sets the DEBUG setting to True prior to running tests. This may help troubleshoot test failures.
Related
I have a problem using Junit tests with Java and Eclipse. All of my tests run just fine when I invoke them standalone. By this I mean that HDLmTreeTest, HDLmTreeTest1, and HDLmTreeTest2 all run fine when I run them by themselves. However, I have a Java source module with all of the test files in it. See below.
package com.headlamp;
import org.junit.platform.runner.JUnitPlatform;
import org.junit.platform.suite.api.SelectClasses;
import org.junit.runner.RunWith;
#RunWith(JUnitPlatform.class)
#SelectClasses({HDLmConfigTest.class, HDLmDefinesTest.class,
HDLmErrorTest.class, HDLmStringTest.class, HDLmTreeTest.class,
HDLmTreeTest1.class, HDLmTreeTest2.class,
HDLmModTest.class, HDLmBuildJSTest.class, HDLmFindTest.class,
HDLmAssertTest.class, HDLmBuildLinesTest.class, HDLmUtilityTest.class,
HDLmSavedChangeTest.class, HDLmCurlApacheTest.class, HDLmMainTest.class,
HDLmJettyTest.class, HDLmCurlJettyTest.class, HDLmEditorServletTest.class,
HDLmApacheTest.class, HDLmProxyTest.class, HDLmSessionTest.class,
HDLmLogMsgTest.class, HDLmMatchTest.class, HDLmImageInformationTest.class,
HDLmClusteringTest.class, HDLmJsonTest.class})
class HDLmAllTests { }
When I run this file, all of my tests get invoked except for HDLmTreeTest1.class and HDLmTreeTest2.class. I should say that HDLmTreeTest1.class and HDLmTreeTest2.class were just recently created and added to the SelectClasses list. For some reason, they are not invoked, but all of the other classes are invoked. What am I doing wrong?
I figured this out (with lots of online help). The problem was the name(s) of my test classes. Test classes (the names of test classes) must end with 'Test' or 'Tests'. They can not end with 'Test1' or 'Test2'. That was my error. I changed the class names and the problem went away. See https://howtodoinjava.com/junit5/junit5-test-suites-examples/ for some details.
I am trying to write a simple function to test why numba.cuda isn't working. The function should set a variable to a fixed value. When I call the function, it seems to compile, but nothing happens. I added, that it should raise an exception, just to see, that it gets called, but again nothing happens. I don't get any kind of exception to give me a hint, why it is not working.
Function:
from numba import cuda
#cuda.jit # also tried it with brackets: #cuda.jit()
def cuda_func(out):
out = 1
raise NameError('MyException')
I call the funtction like this:
>>> import Cuda_Class
>>> a = 0
>>> Cuda_Class.cuda_func[1, 1](a)
>>> a
0
numba.cuda.is_available returns True.
I am working inside a miniconda environment and had some trouble with installing cuda. I accidentally installed multiple versions, so I had to purge everything, and installed cuda 10.2 in my base environment. In the conda environment I installed the cudatoolkit (10.2.89).
I set CUDA_HOME to /usr/local/cuda-10.2. So nvcc --version gives me the right version. So the compiler is accessible.
NUMBA_CUDA_DRIVER should lead to cudalib.so, which I had trouble finding. I did not manually install the nvidia driver, it was installed in combination with cuda. I found cudalib.so under /usr/local/cuda-10.2/targets/x86_64-linux/lib/stubs/libcuda.so. There was no other file named libcuda.so, only libcuda.so.7. However, even before I set NUMBA_CUDA_DRIVER and it was empty, the behavior was exactly the same. No reaction, no exceptions. It looks as if the function would be called correctly, but nothing happens.
The only idea I have left is, that maybe it is a problem, that libcuda.so is in a "stubs" folder?
The first comment solved my problem:
I tried to change the value of an immutable Integer.
Although raise is supported by numba.cuda, apparently exceptions are not supported.
Neither of those mistakes lead to an error message.
Changing "out" to an array and manipulating the first value works.
I'm trying to deploy an app to production and getting a little confused by environment and application variables and what is happening at compile time vs runtime.
In my app, I have a genserver process that requires a token to operate. So I use config/releases.exs to set the token variable at runtime:
# config/releases.exs
import Config
config :my_app, :my_token, System.fetch_env!("MY_TOKEN")
Then I have a bit of code that looks a bit like this:
defmodule MyApp.SomeService do
use SomeBehaviour, token: Application.get_env(:my_app, :my_token),
other_config: :stuff
...
end
In production the genserver process (which does some http stuff) gives me 403 errors suggesting the token isn't there. So can I clarify, is the use keyword getting evaluated at compile time (in which case the application environment doest exist yet)?
If so, what is the correct way of getting runtime environment variables in to a service like this. Is it more correct to define the config in application.ex when starting the process? eg
children = [
{MyApp.SomeService, [
token: Application.get_env(:my_app, :my_token),
other_config: :stuff
]}
...
]
Supervisor.start_link(children, opts)
I may have answered my own questions here, but would be helpful to get someone who knows what they're doing confirm and point me in the right way. Thanks
elixir has two stages: compilation and runtime, both written in Elixir itself. To clearly understand what happens when one should figure out, that everything is macro and Elixir, during compilation stage, expands these macros until everything is expanded. That AST comes to runtime.
In your example, use SomeBehaviour, foo: :bar is implicitly calling SomeBehaviour.__using__/1 macro. To expand the AST, it requires the argument (keyword list) to be expanded as well. Hence, Application.get_env(:my_app, :my_token) call happens in compile time.
There are many possibilities to move it to runtime. If you are the owner of SomeBehaviour, make it accept the pair {:my_app, :my_token} and call Application.get_env/2 somewhere from inside it.
Or, as you suggested, pass it as a parameter to children; this code belongs to function body, meaning it won’t be attempted to expand during compilation stage, but would rather be passed as AST to the resulting BEAM to be executed in runtime.
I am having issues writing a test case for one of my controller actions which uses MySQL syntax. This is because my test environment database is sqlite3, so the syntax is not recognized.
I was looking for a way to customize which environment my test case runs in, and I found this answer, which I tried here:
Rspec.describe MyController, type :controller do
before do
allow(Rails).to receive(:env).and_return(ActiveSupport::StringInquirer.new("development"))
end
... my actual tests ...
but, it didn't work; I am still getting a
SQLite3::SQLException: no such function
Any suggestions?
While working through a tutorial to start learning Grails, I made a mistake and ran:
grails create-domain-class com.FooBar
instead of:
grails create-domain-class com.acme.FooBar
It was immediately obvious I had made an error so I tried the following:
Searched for a function that reverses the create-domain-class command, it seems there isn't one.
Searched for advice on the web and the consensus is that you can delete a domain class file, any associated views and tests, then to be safe run a text search for your class name in your project directory for any references you may have missed. I have done all this.
Then I ran the correct command to create com.acme.FooBar, which worked.
After this the app fails to run and reports the following error:
org.hibernate.DuplicateMappingException: duplicate import: FooBar refers to both com.acme.FooBar and com.FooBar (try using auto-import="false")
After adding the following code to com.acme.FooBar:
...
static mapping = {
autoImport false
}
...
The app now runs as expected.
However as an experienced Java developer who occasionally does refactor a package I would like to understand how to do that without causing a DuplicateMappingException or resorting to the "autoImport false" solution.
Thanks.
You shouldn't be doing
static mapping = {
autoImport false
}
As, by doing this you said that don't check for domain just by name and look up for package as well. Hence, once you do that you will have to use Fully qualified name of the class in your queries / hqls which may itch sometimes.
You should be removing the Domain completely i.e.
remove the Domain
remove the view folder creating by default with very same name and so do the controller
Now, do grails clean-all(Make it a thumb rule to use grails clean-all first for any issue unexpectedly occuring).
To be more accurate do remove target directory from your project and then do run grails run-app.
I had done very same thing many times and got it resolved by above steps.
Hope it helps.