I need to completely disable the SwiftMailer spooling functionality for some of my unit tests.
I have methods that implement application-specific functionality on top of SwiftMailer and I have unit tests for them.
Unfortunately, it appears that SwiftMailer's listener that sends mail spooled to memory at the end of a request is not run during unit testing.
This means that messages spooled to memory are lost. If I spool to a file then I have to manually run the console/swiftmailer:spool:send command. Yes. I know that I could run that command from within my test, but that really doesn't seem very clean and is subject to failure if the syntax of the send command is ever changed.
I have tried removing the swiftmailer.spool configuration from config.yml and specifying it only in config_dev.yml and config_prod.yml, leaving it out of config_test.yml. This has had no effect.
In fact, I have been utterly unable to get rid of the default spool configuration.
I have been using the console config:debug swiftmailer --env=[whetever] to test after each change and the spool configuration is always there with type:memory unless I explicitly set the type to file.
Suggestions?
Many thanks.
Related
I am trying to load test Nginx installed on an EC2 instance via Jmeter, Everytime I try to load test, only 50% request are successful,
For Eg:
If I try with 10 users, only 5 response are OK
If I try with 100 users, only 50 response are OK
If I try with 500, only 250 response are OK
Any Idea, regarding this strange behavior?
This sounds weird. I would recommend the following troubleshooting techniques:
First of all always check jmeter.log file, it should contain enough information to get to the bottom of your test failure(s).
If JMeter log file doesn't contain any suspicious entries next step would be checking response messages using i.e. View Results In Table and/or View Results Tree listener. This should provide you some high-level information and trends, i.e. you will be able to see if some particular sampler(s) is(are) always failing.
If above steps don't give enough clue to resolve your issue you can temporary enable saving of request and response data to see what is wrong with the failing sampler(s). Add the next lines to user.properties file (located in JMeter's "bin" folder)
jmeter.save.saveservice.output_format=xml
jmeter.save.saveservice.response_data=true
jmeter.save.saveservice.samplerData=true
jmeter.save.saveservice.requestHeaders=true
jmeter.save.saveservice.responseHeaders=true
jmeter.save.saveservice.url=true
and next time your run JMeter test the .jtl results file will contain all the relevant data which can be analyzed using aforementioned View Results Tree listener. Don't forget to revert the change once you fix the script as JMeter listeners are very resource intensive per se and above settings greatly increase disk IO and it may ruin your test.
If none of above helps - check logs on the application under test side, most probably you will get something from them.
We have TFS 2015 setup with team build alerts. If I create a team alert for Check-ins, all members of the team successfully get an email on code checked-in. If I create a build failure alert and then get the build to fail, no alerts are received by the team. I don't understand why one would work and the other doesn't. SMTP must be setup fine as are team permissions. What could it be? Is there any where i can see logs?
It turns out to be a bug in the version of TFS that we are using (SP1) which is fixed in a later update (SP2 or 3). The issue was build events were not being raised by the TfsJobAgent due to an error:
Exception Message: TF10121: The path '$(SourcePath)' is not found or not supported. Type or select a different path. (type InvalidPathException)
The $(SourcePath) TFS variable is apparently broken but can be bypassed if updated to the SourcePath in the Variables Tab:
I have updated our builds with so they are using this qualified SourcePath. Build Failure notification emails now being received if you break the build. Apparently Slack integration is now also working!
This is apparently an issue in SP1 and is fixed in later service packs
To narrow down this issue, you can try with below ways:
Set alerts just for yourself to see if you can get an e-mail when the
build fail. Detail ways please refer Set alerts, get notified when
changes occur
Double check the query which the alert is based on, there is a default template, you can use it directly such as below picture
Try to use other build alters such as a build completes to see
whether it works
Look for if there are some related errors in Event Log
I have stop and restart services(Sharepoint Administration & Sharepoint Timer Service)
I cleaned the Configuration Cache by using mentioned steps.
Summary of the steps to clear the timer job:
Stop SharePoint Timer service on all servers in the farm.
Browse to C:\ProgramData\Microsoft\SharePoint\Config{GUID} where the {GUID} folder contains a bunch of XML files and NOT the files with a “.PERSITEDFILE” extension.
Delete all the XML files
Update the contents of the Cache.ini file to just say “1” (without quotes).
Restart the SharePoint Timer service on each server
Reanalyze the issue in Health Analyzer
Does anyone know why this keeps occurring and how I can stop it?
First of all try and check your ULS Logs and see if there is any error that arise.
Secondly try and maybe check the event viewer on your SharePoint server to see if any errors are shown and make sure you have enough disk space available.
and also you might want to check this :Clearing Timer Services
Let me know if you see any error post it here.
hope it helps.
Yotam.
We have continuous integration on our build server. The program which is automatic tested after every checkin sends some emails. We want to send these emails to the user who made the checkin. Is there any way to get the name uf the user who made the checkin when starting the unit tests.
Best would be, if we can access somehow the name of that user who made the checkin in the AssemblyInitialize Method.
Note: This request is not about sending the test report, it is about changing an email in the configuration file of the application before running all unittests.
You can change the build process workflow to get from the current Shelveset (the type is defined in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\Microsoft.TeamFoundation.VersionControl.Client.dll) the OwnerDisplayName (currently it is only the login name with domain so you should do some AD lookup to get the plain name and EMail from AD).
Once you have this information you can check if the test outcome was gree or not. If not an exception is raised in the default template. Catch it and send mail to the user and rethrow the exception.
At test level it is not possible to see it since TFS has test agents which
Can run on another machine thant the build agent (no source code, no sourc control, ...)
Can run distributed on several machines in parallel (send failure mail 6 times from your tester?)
You are trying to solve a problem at the wrong level (inside tests). You can change the Build Process template with no issues quite easy.
I have a long-running unit test job in hudson. If some tests fail I want to run them first and not wait for other tests to run before them (to see, have I fixed them, or not).
Is it possible to setup this in Hudson?
Thanks.
I have the same issue before, here is my solution.
You can write a standalone program to run a list of unit test cases. (In my case, I wrote a Java main class to run Junit manually.)
Create a job that can run with "Trigger builds remotely" and pass the list from the url
Use Selenium to grab the failure result from Hudson's "Test Result"
Use Selenium to trigger the job from "Trigger builds remotely" with the failure list.
By the way, you can also send a mail with the result when the rerun testing failure, and then you can just check mail if the test is real "failure".
Note that the Selenium is not necessary if you have another choice.
Don't think it's possible in Hudson, but if you're using Eclipse (sorry I'm assuming you're using Java), you can run the tests, and re-run them using 'Rerun Test - Failures First'.