Thanks a lot for the response. Meanwhile I have tried adding packge dependency in Project.toml present in the test folder and it works!. I am not sure if this is the right solution.
IIRC, if specified without arg, it defaults to « @. », that is, the Base.current_project() (which should have been named englobing_project imho). It is the first directory up, starting with current, that contains a Project.toml, and, if none, the ~/.julia/environments/v1.x where 1.x is the current Julia version. Maybe I am picky, but this is a significant difference if non existing project that you want to use or create (eg., to create the project in current dir, either use —project=. , or ]activate ., not —project nor —project=@.)
—project=., use ./Project.toml (it is really same as above, with dir=.)
—project=@string, use ~/.julia /environments/string/Project.toml, except if string is .
If no —project, default is @v1.7 if e.g. using Julia 1.7.x
If —project or —project=@., use englobing project : Base.current_project() - this can be ./Project.toml if it exists - BUT if it does not exists, check where it is before ]add or ]rm, because it could modify a Project.toml in an unexpected place.
You can check where is the activated project (the one operated upon) by ]status or Base.active_project()
IMHO, the interest of @string is to be able to share Projects in a common place; the interest of @. is for developing a package, e.g. launching Julia in package/src/ whence the Project is at package/Project.toml (in the directory one level up). So you can use julia —project whenever/anywhere developing inside subdirectories in a package/project, and use the same Project in all cases.