Testing Best Practices: Big Peers, Small Peers, and Identity Switching

follow this guide to help you test changes you make to your ditto integration code, data models, and business logic in addition to their production app in the portal, most developers operate two additional apps one for development and another for staging a staging instance is set up as a pre release sandbox that can simulate real world environments and data big peer testing in a cloud environment offers scalability, flexibility, and cost efficiency by allowing dynamic resource allocation and parallel testing it provides consistent, reproducible environments for reliable results and supports advanced automated and performance testing capabilities in the big peer, each application is isolated from one another by default in a multi tenant architecture, ensuring robust security and data privacy this design allows multiple tenants to share the same infrastructure while keeping their data and applications completely separate the following approaches allow multiple developers to work on ditto in parallel, without conflict app per environment (dev, stage, prod), prefix collections with developer environment each developer can work within the same app running tests in isolation can be done by prefixing the collection with a unique identifier specific to that developer for example, a collection named john smith orders v3 app per developer each developer creates their own “app” within an organization this creates a sandbox for a developer to isolate work and data from other developers starting a new test would require changing the appid on the small peer how do i migrate data between applications? please contact your dedicated support engineer to help migrate data between apps how to reach us ditto portal log in to your account on the https //portal ditto live/ the https //support ditto live/hc/en us/requests/new is located in the upper right hand side of the portal email send an email to our support team at mailto\ support\@ditto live please include the details of the apps you wish to help migrate data between small peer to test small peer integration in isolation, we suggest using a wrapper library that includes an interface and mock implementation for unit testing ditto can be injected with an offline only instance using an offline license token, and building a wrapper library includes an interface and a mock implementation for unit testing this allows you to test small peer logic and syncing between small peers without relying on the availability of a big peer, which is great for testing within a ci/cd pipeline identity switching when testing the production readiness of your app, it is best practice to incorporate dynamic identity switching to debug potential issues related to roles, permissions, sync, and authentication workflows, such as cleanup and resource management when changing identities within your app in dynamic identity switching, end user types adjust in realtime as a response to specific contexts or situations, without requiring an app restart or code change from the end user perspective, this automatic process means no interruptions or inconveniences like needing to log in again while testing with different digital identities is recommended during pre production testing, this practice is not recommended for production environments due to potential performance and security concerns to incorporate the process of automatically changing end user types at runtime var ditto ditto? = nil ditto = ditto( )var ditto ditto? = null ditto = ditto( ) // or ditto? close() ditto = ditto( )let ditto = null; let ditto = new ditto( ); // or ditto close(); let ditto = new ditto( );ditto ditto = null; ditto = new ditto( ); // or ditto close(); ditto = new ditto( );ditto ditto = null; ditto = new ditto( ); // or ditto close(); ditto = new ditto( );ditto ditto = nullptr; ditto = new ditto( ); // or delete ditto; ditto = new ditto( );let mut ditto option\<ditto> = none; ditto = some(ditto new( )); // or ditto = none; ditto = some(ditto new( )); ditto will persist data on each device data within the sandboxed application will be treated as new data and continue to sync, even if the developer changes the appid we suggest changing the persistence directory to prepend the appid to the path to avoid this see the https //github com/getditto/samples/tree/main/testing for testing the small peer by leveraging the offlineplayground identity and changing the persistence directory to prepend the appid to the path example usage in ios app for a realworld implementation of switching user identities in swift, see the https //github com/getditto/dittoswifttools/tree/f5938eb40a8fc3a3a73f87bb95745087903988b4/dittotoolsapp in the getditto > dittoswifttools repository on github in this implementation, the dittomanager https //github com/getditto/dittoswifttools/blob/f5938eb40a8fc3a3a73f87bb95745087903988b4/dittotoolsapp/dittotoolsapp/dittomanager swift#l51 method class configures, manages, and interacts with authentication functionality in the app faq can i mock the big peer or small peer for ci use? we don’t have anything to provide today can i run the big peer on my local laptop? we don’t have this yet, but it’s on the roadmap is it a problem to have multiple apps? no, it is designed for multi tenancy