Coder Social home page Coder Social logo

system_test's Introduction

System Tests

A black/grey box suite that tests the functionality of the 0Chain network as an end user via the CLI tools.

Running tests

The tests require a full 0Chain network to be deployed and running in a healthy state.

Deploy a new 0Chain network and run tests with the system tests pipeline (RECOMMENDED)

system-tests drawio(1) drawio

The System Tests Pipeline can deploy a new 0Chain network with a custom set of docker images then run tests:

[Click to show screenshot] ci-deploy

In this mode, do not supply the network URL. Supply the docker images you wish to deploy

You can view a list available 0chain docker images at Docker Hub, or build your own by running the docker build pipeline in the repo of your feature branch.

0Chain will automatically be deployed to a free test slot at dev-[1-5].devnet-0chain.net. You can view the network URL of deployment by checking the "VIEW TEST CONFIGURATION" step of the pipeline.

[Click to show screenshot] ci-config

If tests fail, the network will stay available for debugging purposes, however uptime is not guaranteed as the network may be overridden by another test run.

Run system tests to unblock merging code changes spanning multiple repos protected by automatic system tests

There may arise a scenario when PRs will fail against default system tests. Consider this, you raise a PR on zboxcli, blobber and 0chain repos simultaneously that only work with new code on all three of them. In this case the PRs raised on all 3 of them will fail system tests because the PR raised on zboxcli will have the new code in that zboxcli branch, but not the required blobber or 0chain code, and so on for the other 2 repos.

In such a case, go to actions tab on any of the repos, find the 0Chain System Tests workflow (like here), input all the custom branches and run it manually. After the completion, all the PRs used in this manual run will be updated to the status of the run (green on success, red otherwise).

Note: While trying to run this workflow manually, if you do not see an input field to one of the repos you want to use, just look in a different repo's actions. This is because GitHub only allows 10 input params, but all params should be covered in different repos.

Updating system tests along with change in another repo

If you need to update system tests according to a PR in some other repos, the protocol is:

  • Make a feature branch on system tests repo with the updated tests
  • Run system tests from any one of those repos manually against this feature branch, passing should make those PRs green.
  • Merge all the other PRs in different repos.
  • This feature branch will now pass against default config, and should be ready to merge.

Run tests against an existing 0Chain network with the system tests pipeline

The System Tests Pipeline can also run tests against an existing 0Chain network

[Click to show screenshot] ci-predeployed

In this mode, supply the network URL. Docker image input fields will be ignored

Set the network URL field to the 0Chain network you wish to test, without the URL scheme or subdomain. eg. beta.0chain.net

Report

The CI pipeline will generate an HTML report after test execution. In this report you can view logs from any test and see failures at a glance.

report-link

Run tests against an existing 0Chain network locally

Requires BASH shell (UNIX, macOS, WSL) and go

Build or download the zbox and zwallet CLIs, ensuring they are compatible with the network you wish to test. Modify the block_worker field in ./tests/cli_tests/config/zbox_config.yaml to point to the network.

To run the entire test suite (minus tests for known broken features) run:

cp $ZBOX_LOCATION ./tests/cli_tests/ # Copy zbox CLI to test folder
cp $ZWALLET_LOCATION ./tests/cli_tests/ # Copy zwallet CLI to test folder
cd ./tests/cli_tests/
go test -run "^Test[^___]*$" ./... -v

Debug logging can be achieved by running

DEBUG=true go test -run "^Test[^___]*$" ./... -v

Include tests for broken features as part of your test run by running

go test ./... -v

PS: Test suite execution will be slower when running locally vs the system tests pipeline. Output will also be less clear vs the system tests pipeline. Therefore, we recommend using an IDE such as GoLand to run/debug individual tests locally

Run individual tests against local 0chain network

For developing new system tests for code still in developer branches, tests can be run against a locally running chain. Typically, for a 0chain change you will have a PR for several modules that need to work together. For example, 0chain, blobber, GoSDK, zboxcli and zwalletcli.

The first step requires setting up a running chain using the GitHub branches from the PRs. Use the instructions for building a local chain 0chain, add a few blobbers. Make sure you stake the blobbers.

For zboxcli and zwalletcli changes you need to first build the executable and copy into local system test directory. For example:

cd zboxcli
make install
cp ./zbox ../system_test/tests/cli_tests/zbox

cd ../zwalletcli
make zwallet
cp ./zwallet ../system_test/tests/cli_tests/zwallet

Make sure you have the correct system test branch. Now you need to edit system_test/tests/cli_tests/config/zbox_config.yaml Edit the line block_worker: https://dev.0chain.net/dns to the appropriate setting for you, something like

block_worker: http://192.168.1.100:9091

Now open the system_test project in GoLand, you should now be able to run any of the cli_tests in debug.

You can run tests against a remote chain if you have already deployed elsewhere eg. dev.0chain.net

Handling test failures

The test suite/pipeline should pass when ran against a healthy network. If some tests fail, it is likely that a code issue has been introduced. Try running the same tests against another network to rule out environmental issues. If the failure persists, and you believe this to be a false positive, contact the system tests team.

Contributing

Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.

License

MIT

system_test's People

Contributors

anish-squareops avatar avanaur avatar boddumanohar avatar cnlangzi avatar dabasov avatar devyetii avatar din-mukhammed avatar hitenjain14 avatar iamrz1 avatar jayashsatolia403 avatar kishan-dhakan avatar kushthedude avatar littlestar642 avatar lpoli avatar manali-jain-squareops avatar manish-210 avatar mohsenno1 avatar n-is avatar nlok5923 avatar peterlimg avatar princeparmar avatar sanchit011 avatar shahnawaz-creator avatar shalinikum avatar sinanekm avatar sriep avatar ssardana08 avatar stewartie4 avatar sunilmhta avatar yarikrevich avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

system_test's Issues

Deploy an entire blockchain stack (0dns, miner, sharder, blobber etc.) to kubernetes

For a given pipeline that produces a docker image (miner, sharder blobber)
After deploying the docker image for the pipeline to kubernetes

  • Deploy the rest of the blockchain (develop images) if an existing stack is not already running
  • If an existing stack is already running, do nothing unless develop images have changed
  • fail the build if deployment fails

eg. If the pipeline is blobber then deploy the custom blobber image that has just been built alongside develop images of sharder, miner, 0dns etc.

Read/Write token lock/unlock system tests

Implement system acceptance tests that test the read and write token lock/unlock functionality

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • lock then unlock read tokens - wallet is decremented and pool contains locked tokens

  • lock then unlock write tokens - wallet is decremented and pool contains locked tokens

  • lock more tokens than you hold - error

  • lock -1 tokens - error

  • lock zero tokens - error

  • do not specify amount to lock - erorr

  • do not specify length of time to lock -error

  • try to unlock a non-expired token -error

  • try to unlock someone else's expired token - error

  • token accounting (where do the tokens go?)

Following the test style guide and the style of the existing tests

Add golang-ci lint

Rather than pointing out best-practices issue ourselves, lets introduce golangci-lint with industry grade config since we are only at two tests.

Add/remove curator system tests

Implement system acceptance tests that test the add/remove curator functionality

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • Add curator: new wallet should be able to transfer allocation ownership
  • Remove curator: new wallet should no longer be able to transfer allocation ownership
  • Add curator to allocation you don't own (should fail)
  • Add for allocation that does not exist

Block rewards token accounting system tests

Investigate and Implement system acceptance tests that test token accounting for block rewards

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

When a block is mined:

  • how are these rewards split between service providers?
  • What wallet do these rewards come from and where do they go?

https://drive.google.com/file/d/1tNjb_OvX93s47QQ2gFrfeUBdmP0PcL9k/view will be an invaluable resource, also chat to the blockchain devs

Following the test style guide and the style of the existing tests

Update Allocation system tests

Implement system acceptance tests that test the allocation update functionality

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • update allocation expiry
  • update allocation size
  • update allocation data shards
  • update allocation parity shards
  • update allocation read price range
  • update allocation write price range
  • update with all of the above at once
  • update allocation with nothing changed
  • Expire an allocation
  • Finalize an allocation
  • update non-existent allocation
  • the usual params checks : -1 as a value, required param not supplied etc.

Following the test style guide and the style of the existing tests

Update file system tests

Investigate and Implement system acceptance tests that test file update functionality

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • Update existing file

  • Update with thumbnail

  • Update with commit

  • Update existing file in another allocation

  • Update file to be larger than the allocation allows

  • Update file that does not exist

  • Update non-encrypted file with encrypted file

  • Update encrypted file with encrypted file

  • Update encrypted file with non-encrypted file

  • Update only thumbnail

  • Update directory

  • token accounting: https://drive.google.com/file/d/1tNjb_OvX93s47QQ2gFrfeUBdmP0PcL9k/view will be an invaluable resource, also chat to the blockchain devs

Following the test style guide and the style of the existing tests

Work out how to ensure a test run has ran before a PR is merged to staging

Our current PR process is hectic.

we only ensure unit tests have passed before we merge, and multiple PRs are merged on top of each other without system tests having ran.
Days later we find an issue which wastes dev time debugging and kills system test team progress.

I suggest this could be resolved at the PR level - every feature branch REQUIRES a green system tests run before it merges to staging, after which staging REQUIRES a green tests run before any other PR can be merged.

If an issue is broken it should be rolled back, not debugged on staging.

Transfer allocation system tests

Implement system acceptance tests that test the allocation transfer functionality

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • transfer empty allocation - what happens to tokens in the old owner's wallet/write pool, what happens to tokens in the new owner's wallet/write pool

  • transfer allocation with encrypted file - can the encrypted file still be used by the new owner

  • transfer allocation with non encrypted file - can the encrypted file still be used by the new owner

  • transfer allocation - allocation cannot be used by previous owner

  • transfer allocation - what happens to files shared/auth tickets issued by the previous owner?

  • transfer allocation - what happens to collaborators added by the previous owner?

  • transfer allocation - what happens to curators added by the previous owner?

  • transfer with invalid wallet id

  • transfer with invalid public key

  • transfer to yourself

  • transfer expired allocation

  • transfer finalized an allocation

  • transfer non-existent allocation

  • the usual params checks : -1 as a value, required param not supplied etc.

  • token accounting - how does a transfer of an allocation affect the pools of the blobbers (if at all) and the wallet of the old owner and the wallet of the new owner? - does the old owner get their tokens back?

Following the test style guide and the style of the existing tests

Interest token lock/unlock system tests

Implement system acceptance tests that test the interest token lock/unlock functionality

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • lock interest tokens - wallet is decremented and pool contains locked tokens

  • unlock interest tokens - wallet is incremented and pool no longer contains locked tokens

  • lock more tokens than you hold - error

  • lock -1 tokens - error

  • lock zero tokens - error

  • do not specify amount to lock - erorr

  • do not specify length of time to lock -error

  • try to unlock a non-expired token -error

  • try to unlock someone else's expired token - error

  • token accounting (where do the tokens go?)

Following the test style guide and the style of the existing tests

Create Allocation system tests

Implement system acceptance tests that test the allocation create functionality

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • create allocations with smallest/largest possible expiry
  • create allocations with smallest/largest possible size
  • create allocations with smallest/largest possible data shards
  • create allocations with smallest/largest possible parity shards
  • create allocation with smallest/largest possible read price range
  • create allocation with smallest/largest possible write price range
  • create allocation with each of the above not specified
  • error scenarios
  • token accounting tests (where do tokens go when an allocation is created)

Following the test style guide and the style of the existing tests

Upload system tests

Implement system acceptance tests that test the upload functionality

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • upload file to root
  • upload file to directory
  • upload file to nested directory
  • try to upload to existing file
  • upload with thumbnail
  • upload encrypted
  • try to upload to non-existant allocation
  • try to upload to someone else's allocation
  • try to upload a file that does not exist on the local disk
  • try to upload blank file
  • token accounting (where do tokens go on lock, file upload etc.)

Following the test style guide and the style of the existing tests

Register wallet system tests

Implement system acceptance tests that test the rest of the register wallet functionality (some have already been completed).
example test cases.

  • create multisig wallet
  • restore existing wallet by mnemonic
  • error scenarios

Following the test style guide and the style of the existing tests

File metadata system tests

Implement system acceptance tests that test the file metadata functionality
example (but not exhaustive) test cases:

  • get file metadata on an empty allocation
  • get file metadata in the root directory
  • get file metadata in a sub directory
  • get file metadata by lookuphash
  • get file metadata of another wallet's file
  • supply both file path and lookup hash to list file
  • supply no params

Following the test style guide and the style of the existing tests

Send ZCN/ Balance system tests

Implement system acceptance tests that test the send ZCN and balance functionality
example (but not exhaustive) test cases.

  • single balance on sender wallet (after faucet)
  • zero balance on sender wallet after ZCN sent
  • single balance on target wallet after ZCN received
  • send zcn with a note
  • send zcn without a note
  • attempt to send with zero balance
  • attempt to send to invalid address
  • token accounting tests (ten fees etc.)

Following the test style guide and the style of the existing tests

Share file using auth ticket system tests

Implement system acceptance tests that test the file sharing using auth ticket functionality
AUTH TICKET USING PRE IS ALREADY COMPLETE BUT THE BELOW STILL NEED DONE:

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • share file owned using auth ticket

  • remove auth ticket - file should no longer be accessible

  • expired auth ticket - file should no longer be accessible

  • try to share a file not owned - should be rejected

  • modify auth ticket to fake the client id - should be rejected

  • modify auth ticket so it is blank - should be rejected

  • All of the above using proxy re-encryption with an auth ticket - DONE - #94

  • token accounting (who pays for reads, writes etc.) for all of the above

Following the test style guide and the style of the existing tests

Update CI test runner

Our current CI test output provided by go test is very hard to read at a glance:

image

gotestsum solves these problems by providing clear, colourised output amongst other features, like auto retrying tests failing due to environmental reasons (disabled for now) which we may need to enable in future

image

miner fees system tests using implicit fees

Sync with blobber system tests

Investigate and Implement system acceptance tests that test blobber sync functionality

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • Sync path with 1 file to empty allocation

  • Sync path with 1 file (encrypted) to empty allocation

  • Sync path with multiple files to empty allocation

  • Sync path with multiple files in nested directories to empty allocation

  • Sync path to NON-empty allocation (no filename clashes)

  • Sync path to NON-empty allocation (replace existing files).
    .

  • Sync with chunk size flag

  • Sync with commit flag

  • Sync with cache flag

  • Sync with upload only flag
    .

  • Attempt sync to allocation not owned

  • Attempt sync to non-existing allocation.

is existing token accounting affected by any of the above?

Following the test style guide and the style of the existing tests

repair allocation system tests

Investigate and Implement system acceptance tests that test allocation repair functionality
Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

attempt file repair on single file that needs repaired
attempt file repair on multiple files that needs repaired
attempt file repair on file that does need repaired with a file that does not need repaired
attempt file repair on file that does not exist
attempt file repair using local path that does not exist
don't supply repair path
don't supply root path

Repair by delete
Repair by upload

a system test where we replace all blobbers with new ones with no data loss

Following the test style guide and the style of the existing tests

Collaborator tests: copy, rename, move, delete, update attributes, download

Investigate and Implement system acceptance tests that test collaborator functionality

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • share file owned using collaborator

  • share encrypted file owned using collaborator

  • remove collaborator - file should no longer be accessible

  • try to add a collaborator to file not owned - should be rejected

  • all of the above for operations that support collaborators (try copy, rename, move, delete, update attributes, download operations etc.)

  • write tests for operations that do not support collaborators

Following the test style guide and the style of the existing tests

Update smart contract settings system tests

Investigate and Implement system acceptance tests that test update smart contract settings
Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

sc-update-config,
fc-update-config,
ip-update-config,
mn-update-config
vp-update-config

Following the test style guide and the style of the existing tests

Download system tests

Implement system acceptance tests that test the download functionality

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • download file from root
  • download file from directory
  • download file to from directory
  • try to download to existing file
  • download encrypted
  • try to download from non-existant allocation
  • try to download from someone else's allocation
  • try to download a file that does not exist
  • token accounting (where do tokens go on lock, file download etc.)

Following the test style guide and the style of the existing tests

Modify existing file (copy, rename, move, update file attributes) system tests

Investigate and Implement system acceptance tests that test modify file functionality

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • Copy file
  • Rename file
  • Move file
  • update file attributes
  • Error scenarios for the above (file doesn't exist, invalid filename etc.)
  • Try to do the above in an allocation you don't own
  • Token accounting - do tokens move in any of the above examples? if so where to?

https://drive.google.com/file/d/1tNjb_OvX93s47QQ2gFrfeUBdmP0PcL9k/view will be an invaluable resource for token accounting, also chat to the blockchain devs

Following the test style guide and the style of the existing tests

Get file stats system tests

Implement system acceptance tests that test the file stats functionality

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • get file stats on an empty allocation
  • get file stats in the root directory
  • get file stats in a sub directory
  • get file stats in a nested sub directory
  • get file stats for a file that doesn't exist
  • get file stats of an allocation you don't own
  • supply no params
  • supply incorrect wallet id
  • supply incorrect public key

Following the test style guide and the style of the existing tests

Also see Tyron's comment here: #35 (comment)

Create directory system tests

Implement system acceptance tests that test the create directory functionality.

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • create dir in root
  • create nested dir
  • create dir that already exists
  • invalid dir name
  • don't supply a dir name
  • create dir in non-existant allocation
  • create dir in someone else's allocation

Following the test style guide and the style of the existing tests

Common user functions token accounting system tests

Implement system acceptance tests that test token accounting after a given file modification.

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • File update/rename/move/delete
    user wallets are not charged but blobber should pay to write the marker to the blockchain

  • Send ZCN between wallets: Fee paid to miners

  • create allocation -> how does this affect a given bobbers wallet/pool

  • update allocation -> how does this affect a given bobbers wallet/pool

  • delete allocation -> how does this affect a given bobbers wallet/pool

  • transfer allocation -> how does this affect a given user's wallet/pool

Following the test style guide and the style of the existing tests

File Upload/Download Token accounting system tests

Implement system acceptance tests that test token accounting after a given operation

Example (but not exhaustive) test cases

  • File upload: When a write marker is written, assert that tokens move from the wallet's write pool to the blobber's challenge pool. Assuming the upload was successful, assert that the tokens in the challenge pool move to the blobber's wallet
  • File download: When a read marker is written, assert that tokens move from the wallet's read pool to the blobber's wallet

Following the test style guide and the style of the existing tests

Use underscore in test names.

When you run a test you might get a result like

=== Failed
=== FAIL: tests/cli_tests TestUpdateAllocation/Cancel_Allocation_Should_fail_when_blobber_passes_challenges (16.41s)
=== FAIL: tests/cli_tests TestUpdateAllocation (0.00s)

When you find in files in system_test for Cancel_Allocation_Should_fail_when_blobber_passes_challenges you can't find it. This is because in the code it is Cancel Allocation Should fail when blobber passes challenges. The toolchain has converted space to underscore.

It would be easier for debugging issues if the t.Run name in the code matched the name in the output.

Suggest replacing space with an underscore in t.Run name parameter.

Stake/Unstake token accounting system tests

Implement system acceptance tests that test token accounting after a token stake/unstake

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • stake some tokens - tokens move from clients wallet to pool
  • unstake some tokens - tokens return to the client's wallet with a portion of the block rewards paid to the MSB they staked with

https://drive.google.com/file/d/1tNjb_OvX93s47QQ2gFrfeUBdmP0PcL9k/view will be an invaluable resource, also chat to the blockchain devs

System tests review and tidy up

List file system tests

Implement system acceptance tests that test the file metadata functionality

Example test cases are below but this is not a complete list.
Also create your own, thinking about security, param validation, error messaging, performance etc.

  • list a file on an empty allocation
  • list a file in the root directory
  • list a file in a directory
  • list a file in a nested directory
  • list file by lookuphash
  • list another wallet's file
  • supply both file path and lookup hash to list file
  • list all files using list-all command
  • supply no params

Following the test style guide and the style of the existing tests

0box initial system tests setup

This is the cornerstone story for the wider system tests project.
System tests are concerned with testing the entire running system as a whole, mostly as the end user although some exceptions should be taken with this approach eg. direct db assertions should be used to assert internal state after a feature has executed.

In this story the technology used for the 0box system tests will be decided (ginkgo has been suggested for example)

The technology requirements are as follows:

  1. The entire feature should be tested with no mocks
  2. The framework should support flexible assertions
  3. The results of these tests should be communicated in an easily digestible form
  4. The approach should not test the REST API directly (there are separate tests for this) but rather through the 0box and 0wallet CLIs

Once the technology has been chosen, implement the following simple test case:

  • Register a wallet
    Following the test style guide

  • #5

  • #6

  • Setup a configuration file for the tests to work against

  • Setup GH-Actions to fetch the assets required to run the tests & clean-up once the tests are completed.

free storage tests

Investigate and Implement system acceptance tests that test the free storage functionality

  • max number of free storage tokens per year

Following the test style guide and the style of the existing tests

Changes to update allocation request for 0chain PR620

0chain PR620 0chain/0chain#620 and GoSDK 0chain/gosdk#288 and zbox 0chain/zboxcli#122 make the following changes to update allocation and new allocation request.

1. Allow any user to attempt an update allocation request. Previously GoSDK forced the client and owner to be the same.
2. Extending an allocations expiry date is now allowed by anyone.
3. Reducing the expiry date is no longer permitted.
4. Setting an allocation immutable or changing its size can only be done by the owner.

Requirements changed:

  1. Allocations cannot have their duration reduced.
  2. A new NFT allocation option which can be set in a new allocation request; defaulting to false. It allows anyone to extend the allocation.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.