I try to setup the test environment for unit (jest) testing for my custom plugin vue files in Shopware6 using shopware-docker
The provided documentation is, at least for me, not really helpful. following a list of unclear hints:
What means Module: base vs Module: classic vs Module: platform? Which one i have installed? Where are a useful documentation about? The folder structure does not provide named modules
Like when the target project is Shopware 5 Git installation, to include base + classic or on Shopware 6, base + platform.
I started with Shopware 6, so i confused about this nexus
Trying command swdc admin-jest <project-name> inside Module: platform, the only which appointed the administration, returns:
rammi#rammi-laptop-i7:~/Code/my-project$ swdc admin-jest my-project
Installing Node v12.22.12 (x64)
warning: Version already installed at "/nvm/.debian-fnm/node-versions/v12.22.12"
Using Node v12.22.12
Writing definition to file ...
Done!
Using Node for alias lts-gallium
> administration#1.0.0 unit-watch
> jest --config jest.config.js --watch
No tests found related to files changed since last commit.
Press `a` to run all tests, or run Jest with `--watchAll`.
----------|---------|----------|---------|---------|-------------------
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------|---------|----------|---------|---------|-------------------
All files | 0 | 0 | 0 | 0 |
----------|---------|----------|---------|---------|-------------------
Watch Usage
› Press a to run all tests.
› Press f to run only failed tests.
› Press p to filter by a filename regex pattern.
› Press t to filter by a test name regex pattern.
› Press q to quit watch mode.
› Press Enter to trigger a test run.
Thats all..., but i think, there must be a environment configuration to achieve tests, but i dont find nothing in the official documentations. Also using google without success.
What i found is the command composer run admin:create:test from this documentation. But the command does not exist in shopware-docker repository. And a similar command is not available.
Summary: How to setup jest for custom plugin using shopware-docker?
Edit #1
I have already created a simple test like this
// custom/plugins/MyPlugin/src/Resources/app/administration/test/module/my-module/view/module-view.spec.js
describe('module-view', () => {
it('should be false', () => {
expect(false).toBeTruthy()
})
})
Using the provided command Press p to filter by a filename regex pattern. and putting module-view response with
Watch Usage: Press w to show more.
Active Filters: filename /module-view/
Pattern Mode Usage
› Press Esc to exit pattern mode.
› Press Enter to filter by a filenames regex pattern.
pattern › module-view.spec.js
No tests found, exiting with code 0
----------|---------|----------|---------|---------|-------------------
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------|---------|----------|---------|---------|-------------------
All files | 0 | 0 | 0 | 0 |
----------|---------|----------|---------|---------|-------------------
Watch Usage: Press w to show more.
As i can't use the recommend way by shopware, this is my current solution:
create folder test/e2e in ~/%my_plugin%/src/Resources/app/administration/
go to folder e2e
run npm install cypress --save-dev
run to start cypress node_modules/.bin/cypress open
BTW: the current solution cover e2e tests, but cypress also offer solution for component tests, which can used for unit test
Related
I have a .NET 6 project running with our CICD on aws CcodeDeploy, and here is the error from CodeDeploy deployment:
The CodeDeploy agent did not find an AppSpec file within the unpacked revision directory at revision-relative path "appspec.yml". The revision was unpacked to directory "/opt/codedeploy-agent/deployment-root/{guid}/d-xxxxxxx/deployment-archive", and the AppSpec file was expected but not found at path "/opt/codedeploy-agent/deployment-root/{guid}/d-xxxxxxx/deployment-archive/appspec.yml". Consult the AWS CodeDeploy Appspec documentation for more information at http://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file.html View more.
However, when I login into the LINUX instance and can find the files under /opt/codedeploy-agent/deployment-root/0596c43c-d025-448a-8999-9675455ad44c/d-VE62UHKSH/deployment-archive, but their file name all look like: XXX\wwwroot\locales\zh.json, XXX\appspec.yml. I have no idea why CodeDeloy unzip the file like this which I never ever meet before.
Actually, the source code structure is:
RootFolder
|
| __ wwwroot
| |
| |__ locales
| |
| |__ zh.json
|
|____ Application.dll
|____ appspec.yml
So, anyone who ever met such an issue?
Jest is throwing an error stating it cannot find the module specified by path in jest.mock()
> jest
FAIL test/userSelect.test.ts
● Test suite failed to run
Cannot find module '../src/actions/selectUserById' from 'test/userSelect.test.ts'
8 |
9 | jest.mock('mysql');
> 10 | jest.mock('../src/actions/selectUserById');
11 |
12 | const mockSelectUserById = selectUserById as jest.MockedFunction<
13 | typeof selectUserById
at Resolver.resolveModule (node_modules/jest-resolve/build/index.js:306:11)
00:00
at Object.mock (test/userSelect.test.ts:10:6)
The strangest part is this:
this test passes on my local machine, but it fails in the CI service we are using.
In case anyone else is troubleshooting a similar issue,
I finally realized the root-cause of the failing test was a difference in case-sensitivity of the specified path.
In my case the true filename is src/actions/selectUserByID (notice the uppercase letter 'D'),
but the string I passed to Jest.mock() is selectUserById.
At some point, I renamed the file locally, which is why the test passes as expected on my machine. However, I learned a case-sensitive change to a filename is not detected as a change by git, which is why the CI service still had the erroneous filename.
I used git mv to commit the case-sensitive filename, and this resolved my issue.
As of now I have a simple solution structure(WebAPI projects, which are gonna be microservices) with default generated dockerfiles for each project in the solution, like:
Solution X
| Project A
| | Dockerfile
| Project B
| | Dockerfile
| Project C
| | Dockerfile
| Project D
| | Dockerfile
| azure-pipeline.yml
From the development and debuggind point of view everything works(through "Docker" as launcher), but after creating with the Azure wizard the first pipeline for the "Project A" my build always fails at a COPY instruction at the build step:
COPY ["Project A/ProjectA.csproj", "Project A/"]
With the error from the pipeline run as:
COPY failed: stat /var/lib/docker/tmp/docker-builder196561826/Project A/ProjectA.csproj: no such file or directory
##[error]COPY failed: stat /var/lib/docker/tmp/docker-builder196561826/Project A/ProjectA.csproj: no such file or directory
Am not an expert in docker neither in azure but I guess I'm setting up this solution in the wrong way to accomplish such thing.
What could be a better setup or fix?
no such file or directory
This is a very common error people encountered after they migrate the Docker project from Visual studio into Azure Devops, even they can build docker very successfully in local.
This caused by the different work logic between Visual Studio(local) and Azure Devops. For local, the docker runs at the Repos/solution level. BUT, for Azure devops CI, it running the docker in the directory where the dockerfile lives, which is at project level. At this time, the relevant path which work fine locally, will not suitable in Azure devops any more.
I guess you may not want to make changes to your dockerfile. So here you just need specify the build context in Docker task:
Specify $(Build.Repository.LocalPath) to the Docker 2.* argument Build context.
Check my previous answer.
We have a very stateful NodeJS based web server (Meteor) that occasionally, randomly becomes slow in production. The problem is not reproducible in any of our tests, and we don't know what's triggering it.
To diagnose this, we are using the v8-profiler package. This lets us trigger a 10-second CPU profile and download it for offline analysis.
Despite not having received any commits in 3 years, the package used to work fairly well. It has given us compilation trouble in the past, and now it looks like it stopped compiling entirely, breaking our build. The build happens inside a Docker container with all versions pinned, including NodeJS and v8-profiler itself, so it's unlikely that we can fix this on our end.
I'm thinking there must be some alternative, better maintained approach. But where is it?
(Note that restarting the server with additional flags (like --profile) is not an option, because it destroys all the evidence of the problem.)
I found there has been v8-profiler-next which is a successor of v8-profiler.
I hope this works for you.
I just built a tool for this. Called ntop, so it's like "top" but for Node apps https://github.com/DVLP/ntop
The below will enable communication with the CLI. This is designed to not add any overhead when the CLI tool is not used so it can be used in production. The profiler connects/disconnects immediately only when the CLI is doing the profiling.
The app:
import * as ntop from 'ntop'
ntop()
CLI shortcut to get a list of PIDs for convenience:
npx ntop
Outputs PIDs and additionally the command used to create the process for easier recognition.
Process detected at 12345 Details: node ./src/index.js --port 8216
npx ntop 12345
Outputs a list like "Bottom Up" in Chrome Dev Tools
(garbage collector) | 16.101ms |
shift | 10.038ms | node:internal/priority_queue:98:7
(anonymous) | 9.192ms | file:///home/app/src/controllers/Server.js:24:29
utils.bulkPreparePacket | 4.924ms | file:///home/app/src/Utils.js:91:26
preparePacket | 4.776ms | file:///home/app/src/Model.js:98:54
baseGetTag | 1.727ms | file:///home/app/node_modules/lodash/lodash.js:3104:23
(anonymous) | 1.702ms | evalmachine.:3:14
isPrototype | 1.441ms | file:///home/app/node_modules/lodash/lodash.js:6441:24
(program) | 1.411ms |
percolateDown | 1.124ms | node:internal/priority_queue:40:15
The date is/was 12/17/2014, I'm trying to run gitlab-ce tests from within gitlab-development-kit. I'm hoping someone familiar with gitlab-ce development can help here. I want to have the tests pass before I begin development. I'm not sure if this warrants a bug report, it may be my environment (CentOS 6.5, rvm 1.26.3, ruby 2.1.3p242 )
I followed instructions on gitlab-development-kit to clone it, run make (to download latest gitlab + gitlab-shell).
I run bundle exec foreman start, redis and pgsql start.
Every thing is looking good, I ran gitlab and it worked fine in development env. I reset everything by recloning and following steps and then tested.
Within ./gitlab, I run "rake gitlab:test"; lots of passed, green tests.
Until I the end, I receive this:
...(many, and all, passing tests above here)...
Scenario: Navigate to project feed
✔ Given I sign in as a user # features/steps/shared/authentication.rb:7
✔ And I own a project # features/steps/shared/project.rb:5
✔ And I visit my project's home page # features/steps/shared/paths.rb:169
✔ Given I visit my project's files page # features/steps/shared/paths.rb:177
✔ Given I press "g" and "p" # features/steps/shared/shortcuts.rb:4
✔ Then the active main tab should be Home # features/steps/shared/project_tab.rb:7
/usr/local/rvm/gems/ruby-2.1.3/gems/actionview-4.1.1/lib/action_view/renderer/partial_renderer.rb:436:in `partial_path': 'nil' is not an ActiveModel-compatible object. It must implement :to_partial_path. (ActionView::Template::Error)
from /usr/local/rvm/gems/ruby-2.1.3/gems/actionview-4.1.1/lib/action_view/renderer/partial_renderer.rb:345:in `setup'
from /usr/local/rvm/gems/ruby-2.1.3/gems/actionview-4.1.1/lib/action_view/renderer/partial_renderer.rb:262:in `render'
from /usr/local/rvm/gems/ruby-2.1.3/gems/actionview-4.1.1/lib/action_view/renderer/renderer.rb:47:in `render_partial'
from /usr/local/rvm/gems/ruby-2.1.3/gems/actionview-4.1.1/lib/action_view/helpers/rendering_helper.rb:35:in `render'
from /usr/local/rvm/gems/ruby-2.1.3/gems/haml-4.0.5/lib/haml/helpers/action_view_mods.rb:10:in `block in render_with_haml'
from /usr/local/rvm/gems/ruby-2.1.3/gems/haml-4.0.5/lib/haml/helpers.rb:89:in `non_haml'
from /usr/local/rvm/gems/ruby-2.1.3/gems/haml-4.0.5/lib/haml/helpers/action_view_mods.rb:10:in `render_with_haml'
from /home/git/gitlab-development-kit/gitlab/app/views/projects/blob/_blob.html.haml:20:in `_app_views_projects_blob__blob_html_haml__1171767312904667641_107433960'
from /usr/local/rvm/gems/ruby-2.1.3/gems/actionview-4.1.1/lib/action_view/template.rb:145:in `block in render'
from /usr/local/rvm/gems/ruby-2.1.3/gems/activesupport-4.1.1/lib/active_support/notifications.rb:161:in `instrument'
from /usr/local/rvm/gems/ruby-2.1.3/gems/actionview-4.1.1/lib/action_view/template.rb:339:in `instrument'
from /usr/local/rvm/gems/ruby-2.1.3/gems/actionview-4.1.1/lib/action_view/template.rb:143:in `render'
from /usr/local/rvm/gems/ruby-2.1.3/gems/actionview-4.1.1/lib/action_view/renderer/partial_renderer.rb:306:in `render_partial'
...
When I inspect app/views/projects/blob/_blob.html.haml:20
I can see
%ul.blob-commit-info.bs-callout.bs-callout-info.hidden-xs
- blob_commit = #repository.last_commit_for_path(#commit.id, #blob.path)
= render blob_commit, project: #project
The error is complaining because blob_commit is nil, from the line
#repository.last_commit_for_path(#commit.id, #blob.path)
This is a pure clone of everything, I haven't began to make modifications yet. I waited a day to see if maybe the next update would fix things but it hasn't. I don't want to start a feature branch if I'm already having failing tests.
I found out the answer to my problem.
CentOS 6.5 hasn't upgraded their git rpm to anything beyond 1.7.1
I added some debugging to app/models/repository.rb, in def commit(id = HEAD), and def last_commit_for_path(sha, path)
It appears that in last_commit_for_path, on gitlab-test_bare, the following command is run:
git rev-list --max-count 1 5937ac0a7beb003549fc5fd26fc247adbce4a52e -- CHANGELOG
which results in an exception
fatal: bad revision '1'
which results in '#'repository.last_commit line above to assign nil to blob_commit.
It looks like --max-count 1, in my environment, must be --max-count=1.
git rev-list --max-count=1 5937ac0a7beb003549fc5fd26fc247adbce4a52e -- CHANGELOG
which results in a valid commit sha
913c66a37b4a45b9769037c55c2d238bd0942d2e
When I looked at my git version, i noticed it was extremely out of date (1.7 vs 2.2) so I updated using source and the tests pass since gitlab can execute the --max-count 1 as a parameter to git.