pages on creating, testing and deploying smart contract

[LiYuxin44]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs-staging	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 16, 2023 2:49pm

[timothymcmackin]

Good start. Here are some thoughts. We can discuss on Monday:

• Go ahead and put these as pages directly under docs/smart-contracts instead of in the creating-testing-deploying-smart-contract folder.
• Use sentence-style capitalization for page titles and headings, like "Testing smart contracts."
• These are independent topics that people may access in any order, so don't refer to things like "in the next chapter" or "in the next section, we will see how to..."
• Use a more direct style, such as avoiding passive voice in sentences such as "After the smart contract has successfully been originated and included in a baked block, interaction with the contract's entrypoints is possible via command lines."
• For Testing: What kinds of tests should I create? Check the existing file docs/smart-contracts/testing.md, which is taken from opentezos. There's also info in opentezos on testing frameworks for the different languages and we could provide examples of an automated test in a smartpy contract.
• For Creating: think about the task of creating a contract from the perspective of a developer, and maybe ask some developers about what they think about and plan for before creating a contract. Do they start from a template or start from scratch? What do they consider before defining the storage and its data types? How do they plan the entrypoints? For example, they probably think of the entrypoints as accepting parameters instead of a parameter and the storage, although when they code it, the entrypoint receives the storage as a parameter.
• This PR renames the docusaurus start script and installed a different version of docusaurus.
• This is subjective, but I think it's overdoing it to use bold for an item at the start of lists, as in "- Functionality Tests: Verifying that all contract functions perform as intended under normal conditions." The list will already show up with a bullet and draw attention; overusing bold can make it less effective, but I know that a lot of people use it this way.

Sorry I'm not able to provide more detail now -- github was down for me part of friday.

[timothymcmackin]

• This is headed in the right direction, particularly the testing and deploying pages because they cover some of the steps and the thought process behind the tasks.
• Go ahead and overwrite the existing testing topic after you take what you want from it instead of creating testing2.md.
• It doesn't really matter that this PR updates package-lock.json, but ideally a PR shouldn't contain unrelated changes. You can remove the changes with a command like git checkout staging package-lock.json.
• Make sure you've covered the prerequisites for these tasks. For example, before you can deploy a smart contract, you have to compile it and possibly its initial storage. To use the octez originate command, you need to set up an account in it with some tez to pay the fees. Go over these very carefully and make sure you're not skipping any prereqs or steps.
• Consistency: make sure headings and list items are parallel in format and style. Some of the headings end in periods and others don't. Some use -ing verbs and others don't.

[timothymcmackin]

ok, just corrected a few broken links.